JDK 25 HttpClient는 SOCKS ProxySelector 경로를 사용하지 않는다

Java 프록시 객체는 경로를 설명할 뿐입니다. 어떤 종류의 경로를 사용할 수 있는지는 여전히 네트워크 클라이언트가 결정합니다. 사용 가능한 엔드포인트가 SOCKS를 말하고 애플리케이션이 java.net.http.HttpClient를 사용할 때 이 점이 중요합니다.

여기서 살펴보는 JDK 25 구현에서 HTTP 클라이언트의 요청 코드는 선택기에서 HTTP 후보를 받아들입니다. SOCKS 후보는 SOCKS 협상을 수행하게 하지 않으며, 구현은 프록시 없이 계속 진행할 수 있습니다. 따라서 성공적인 응답만으로는 사용자 지정 선택기의 SOCKS 항목이 사용되었다는 충분한 증거가 되지 않습니다.

먼저 전송을 선택하세요

기존 URLConnection 기반 애플리케이션에서는 연결을 열 때 프로토콜 핸들러에 지원되는 명시적 프록시를 전달할 수 있습니다:

Proxy route = new Proxy(Proxy.Type.SOCKS,
    new InetSocketAddress("proxy.example", 1080));
URLConnection connection = URI.create("https://service.example/")
    .toURL().openConnection(route);
connection.setConnectTimeout(5000);
connection.setReadTimeout(15000);

허용된 공개 대상 테스트에는 서비스나 SOCKS 프록시 목록에서 일치하는 SOCKS 엔드포인트를 사용하세요. 이것은 다른 클라이언트 API이며 HttpClient.Builder.proxy의 다른 표기가 아닙니다. HTTPS가 의도한 웹사이트를 계속 식별하도록 대상 URL을 유지하세요.

java.net.http를 유지해야 하는 애플리케이션은 대신 이후 SOCKS 연결을 처리하는 승인된 어댑터를 포함한 호환 HTTP 프록시 엔드포인트를 사용할 수 있습니다. 이는 실제 구성 요소와 또 하나의 접근 경계를 추가합니다. 포트 8080을 1080으로 바꾼다고 해서 그 변환이 제공되지는 않습니다.

선택과 채택을 가시화하세요

선택기의 결과와 클라이언트가 실제로 여는 연결을 모두 기록하세요. 전자는 정책 출력을 설명하고, 후자는 구현이 이를 채택했는지 확인합니다.

결론은 사용 중인 런타임과 전송에 연결하세요. 하나의 소켓 구현이 사용하는 JVM SOCKS 속성이 모든 HTTP 라이브러리가 이를 참조한다는 약속은 아닙니다. 경로가 필수라면 겉보기에 성공한 직접 요청을 받아들이기 전에 지원되지 않는 프록시 유형을 탐지해야 합니다.