Hvorfor Java valgte en SOCKS-proxy til din HTTP-anmodning

Undersøg ProxySelector-resultatet og de effektive JVM-indstillinger, før du anvender gamle Windows-proxyworkarounds.

En Java-anmodning kan møde flere proxykilder: eksplicit klientkonfiguration, standardvælgeren, JVM's netværksegenskaber og understøttede operativsystemindstillinger. Når en log uventet nævner SOCKS, skal du identificere, hvilken kilde der valgte den.

For kode, der bruger standardvælgeren, skal du undersøge beslutningen for den præcise destination:

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

Dette rapporterer vælgerens kandidater. Det beviser ikke, hvilken forbindelse der i sidste ende lykkedes, og en klient med sin egen eksplicitte rute kan træffe et andet valg.

Kontroller de effektive indstillinger

Gennemgå http.proxyHost, https.proxyHost, socksProxyHost, deres porte og java.net.useSystemProxies. JDK-dokumentationen om netværksegenskaber beskriver deres omfang og forrang. Registrering af systemproxy kontrolleres ved opstart; angiv den bevidst, når JVM'en startes.

Historiske svar beskriver specifikke kombinationer af gamle Windows-dialoger og gamle JDK'er. De rapporter kan forklare oprindelsen af en workaround, men de fastslår ikke, at en nuværende runtime har samme fejl. Notér runtime-versionen og vælgerens output, før du ændrer operativsystemindstillinger for alle programmer.

Hvis programmet har brug for en HTTP-proxy til én klient, kan en eksplicit proxykonfiguration gøre det krav tydeligere. Hvis det har brug for central automatisk routing, skal du undersøge, hvorfor vælgeren modtog eller returnerede den uventede SOCKS-post.

En brugerdefineret vælger bør bevare tilsigtede omgåelser og fejlhåndtering. Filtrering af alle SOCKS-kandidater uden skel kan bryde forbindelser, der skulle bruge en. Ret den forkerte regel med det mindste omfang, du kan identificere.

Relaterede artikler