Varför Java valde en SOCKS-proxy för din HTTP-förfrågan

Granska ProxySelector-resultatet och de effektiva JVM-inställningarna innan du använder gamla Windows-proxyworkarounds.

En Java-förfrågan kan möta flera proxyindata: explicit klientkonfiguration, standardväljaren, JVM:s nätverksegenskaper och operativsystemets inställningar som stöds. När en logg oväntat nämner SOCKS, identifiera vilket indata som valde det.

För kod som använder standardväljaren, granska beslutet för den exakta destinationen:

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

Detta rapporterar väljarens kandidater. Det bevisar inte vilken anslutning som till slut lyckades, och en klient med egen explicit väg kan göra ett annat val.

Kontrollera de effektiva inställningarna

Granska http.proxyHost, https.proxyHost, socksProxyHost, deras portar och java.net.useSystemProxies. JDK-dokumentationen om nätverksegenskaper beskriver deras omfattning och prioritet. Upptäckt av systemproxy kontrolleras vid start; ange det medvetet när JVM startas.

Historiska svar beskriver specifika kombinationer av gamla Windows-dialoger och gamla JDK:er. De rapporterna kan förklara ursprunget till en workaround, men de visar inte att en aktuell runtime har samma bugg. Anteckna runtime-versionen och väljarens utdata innan du ändrar operativsystemets inställningar för varje applikation.

Om applikationen behöver en HTTP-proxy för en klient kan en explicit proxykonfiguration göra kravet tydligare. Om den behöver central automatisk routning, undersök varför väljaren tog emot eller returnerade den oväntade SOCKS-posten.

En anpassad väljare bör bevara avsiktliga kringgåenden och felhantering. Att filtrera bort varje SOCKS-kandidat urskillningslöst kan bryta anslutningar som skulle använda en. Åtgärda den felaktiga regeln med den minsta omfattning du kan identifiera.

Relaterade artiklar