It would be better to bring this to the net-dev mailing list as that is where HTTP client issues are discussed. It may be something that has already been looked into for direct (rather than proxied) connections.
-Alan On 26/09/2026 14:08, Rafael Winterhalter wrote:
Hei, java.net.http.HttpClient resolves host names inside its implementation, and there is no per-client way to influence that. The only hook is the JVM-wide InetAddressResolverProvider, and the JDK installs exactly one of those per JVM. This blocks a common SSRF defence. A server that fetches user- or upstream-supplied URLs checks that the host resolves to a public address and then sends the request. HttpClient resolves the name again when it connects, so a name that rebinds between the check and the connect reaches an internal address the check refused. Connecting to the checked address yourself isn't an option either: it breaks TLS host-name verification and SNI. Other clients offer a per-client hook for exactly this: Jetty (SocketAddressResolver), Apache HttpClient (DnsResolver) and OkHttp (Dns). We moved our outbound calls to Jetty's client for this reason alone, while keeping the java.net.http API. Would a per-client resolver on HttpClient.Builder be considered? That could be an InetAddressResolver, or a filter over the resolved addresses. Thanks, Rafael
