Limitations of IntelliJ HTTP Client: DNS Cache Persistence

Direct answer

There is no documented IntelliJ IDEA setting or hidden option to flush an internal DNS cache for the built-in HTTP client or proxy connections in IntelliJ IDEA 2026.1. Name resolution is performed by the JVM and the operating system, and entries remain cached for the life of the running IDE process. The practical workaround is to shorten the JVM DNS TTL and restart IntelliJ.

Likely explanation versus confirmed facts

Likely explanation: after a proxy host IP changes, the IDE may still connect to the old address because the JVM cached the previous InetAddress lookup. Certificate validation errors can follow if the new IP serves a certificate that does not match the configured hostname, or if the IDE is not using the system trust store.

Confirmed behavior: the JVM caches successful and failed host lookups with TTLs controlled by JDK security properties. Restarting the IDE clears the running process's caches. The flags -Dsun.net.inetaddr.ttl and -Dsun.net.inetaddr.negative.ttl are JDK behavior, not an IntelliJ API, and defaults or support may differ in 2026.1.

Steps for this case

1. Open Help > Edit Custom VM Options.
2. Add or update these lines:

-Dsun.net.inetaddr.ttl=30
-Dsun.net.inetaddr.negative.ttl=10

1. Save the file and restart IntelliJ so the new JVM options take effect.
2. Retry the plugin repository or proxy request.

Verification

• Confirm the proxy is configured by hostname, not an IP literal. IP literals bypass DNS and can still cause hostname-verification failures.
• After restart, check that the JVM command line includes the TTL options before retesting.
• If SSLHandshakeException or CertificateException persists, the cause is likely trust-store or hostname mismatch, not DNS. Add the proxy or repository certificate to the IDE trust store or correct the proxy hostname.

Assumptions and uncertainty: This answer assumes standard HotSpot/OpenJDK DNS caching behavior. IntelliJ IDEA 2026.1 is outside stable knowledge, so hidden options and default SSL trust-store handling may differ. Verify in the target build before relying on the VM options. Do not use reflection on internal JDK classes such as sun.net.InetAddressCache; it is unsupported and fragile.

Missing diagnostic detail: please share the exact exception text and whether the proxy is configured by hostname or IP. That determines whether the fix is DNS TTL, trust-store configuration, or hostname correction.