Java が HTTP リクエストに SOCKS プロキシを選んだ理由

Java のリクエストは、複数のプロキシ入力に遭遇する可能性があります。明示的なクライアント設定、デフォルトのセレクター、JVM のネットワークプロパティ、およびサポートされているオペレーティングシステムの設定です。ログに予期せず SOCKS が記録されている場合は、どの入力がそれを選んだのかを特定します。

デフォルトのセレクターを使用するコードでは、正確な宛先に対する判断を確認します。

URI target = URI.create("https://example.com/");
ProxySelector selector = ProxySelector.getDefault();
if (selector != null) {
    System.out.println(selector.select(target));
}

これはセレクターの候補を報告します。どの接続が最終的に成功したかを証明するものではなく、独自の明示的な経路を持つクライアントは別の選択をする可能性があります。

有効な設定を確認する

http.proxyHost、https.proxyHost、socksProxyHost、それらのポート、および java.net.useSystemProxies を確認します。JDK のネットワークプロパティのドキュメントに、それらの範囲と優先順位が説明されています。システムプロキシの検出は起動時に確認されます。JVM を起動するときに意図的に設定してください。

過去の回答は、古い Windows のダイアログと古い JDK の特定の組み合わせを説明しています。そうした報告は回避策の起源を説明できますが、現在のランタイムに同じバグがあることを証明するものではありません。すべてのアプリケーションのオペレーティングシステム設定を変更する前に、ランタイムのバージョンとセレクターの出力を記録してください。

アプリケーションが 1 つのクライアントに HTTP プロキシを必要とする場合、明示的なプロキシ設定によってその要件を明確にできます。集中管理された自動ルーティングが必要な場合は、セレクターが予期しない SOCKS エントリを受け取った、または返した理由を調査してください。

カスタムセレクターは、意図的なバイパスと失敗の処理を保持すべきです。すべての SOCKS 候補を無差別にフィルタリングすると、1 つを使うはずだった接続を壊す可能性があります。特定できる最小の範囲で誤ったルールを修正してください。