Hvorfor Java valgte en SOCKS-proxy for HTTP-forespørselen din

En Java-forespørsel kan møte flere proxyinndata: eksplisitt klientkonfigurasjon, standardvelgeren, JVM-nettverksegenskaper og støttede operativsysteminnstillinger. Når en logg uventet nevner SOCKS, må du finne ut hvilket inndata som valgte det.

For kode som bruker standardvelgeren, undersøk avgjørelsen for den nøyaktige destinasjonen:

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

Dette rapporterer velgerens kandidater. Det beviser ikke hvilken tilkobling som til slutt lyktes, og en klient med sin egen eksplisitte rute kan gjøre et annet valg.

Kontroller de gjeldende innstillingene

Se gjennom http.proxyHost, https.proxyHost, socksProxyHost, portene deres og java.net.useSystemProxies. JDK-dokumentasjonen for nettverksegenskaper beskriver omfanget og prioriteten deres. Systemproxyoppdagelse kontrolleres ved oppstart; sett det bevisst når du starter JVM-en.

Historiske svar beskriver spesifikke kombinasjoner av gamle Windows-dialoger og gamle JDK-er. Disse rapportene kan forklare opprinnelsen til en workaround, men de fastslår ikke at en nåværende kjøretid har den samme feilen. Registrer kjøretidsversjonen og velgerens utdata før du endrer operativsysteminnstillinger for alle applikasjoner.

Hvis applikasjonen trenger en HTTP-proxy for én klient, kan en eksplisitt proxykonfigurasjon gjøre dette kravet tydeligere. Hvis den trenger sentral automatisk ruting, undersøk hvorfor velgeren mottok eller returnerte den uventede SOCKS-oppføringen.

En tilpasset velger bør bevare tilsiktede omgåelser og feilhåndtering. Å filtrere alle SOCKS-kandidater uten forskjell kan bryte tilkoblinger som skulle bruke en. Rett den feilaktige regelen med det minste omfanget du kan identifisere.