JDK 25 HttpClient は ProxySelector の SOCKS ルートを使用しない

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 を維持しなければならないアプリケーションは、代わりに互換性のある HTTP プロキシエンドポイントを使えます。後続の SOCKS 接続を扱う承認済みアダプターを含む場合もあります。これは実在する構成要素と、もう一つのアクセス境界を追加します。ポート 8080 を 1080 に変えても、その変換は得られません。

選択と採用を可視化する

セレクターの結果と、クライアントが実際に開く接続の両方を記録します。前者はポリシーの出力を表し、後者は実装がそれを採用したかどうかを示します。

結論は、使用中のランタイムとトランスポートに結び付けます。あるソケット実装が使う JVM の SOCKS プロパティは、すべての HTTP ライブラリがそれを参照するという約束ではありません。経路が必須である場合、見かけ上成功した直接要求を受け入れる前に、サポートされないプロキシ種別を検出するべきです。