Kial Java elektis SOCKS-prokurilon por via HTTP-peto

Ekzamenu la rezulton de ProxySelector kaj la efektivajn agordojn de JVM antaŭ ol apliki malnovajn Windows-prokurilajn solvojn.

Java-peto povas renkonti plurajn prokurilajn fontojn: eksplicita klienta agordo, la defaŭlta elektilo, retaj propraĵoj de JVM, kaj subtenataj agordoj de la operaciumo. Kiam protokolo neatendite mencias SOCKS, identigu, kiu fonto elektis ĝin.

Por kodo, kiu uzas la defaŭltan elektilon, ekzamenu la decidon por la preciza celo:

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

Ĉi tio raportas la kandidatojn de la elektilo. Ĝi ne pruvas, kiu konekto finfine sukcesis, kaj kliento kun propra eksplicita vojo povas fari alian elekton.

Kontrolu la efektivajn agordojn

Kontrolu http.proxyHost, https.proxyHost, socksProxyHost, iliajn havenojn, kaj java.net.useSystemProxies. La dokumentaro de retaj propraĵoj de JDK priskribas ilian amplekson kaj prioritaton. Malkovro de sistema prokurilo estas kontrolata ĉe lanĉo; agordu ĝin konscie kiam vi lanĉas la JVM.

Historiaj respondoj priskribas specifajn kombinaĵojn de malnovaj Windows-dialogoj kaj malnovaj JDK-oj. Tiuj raportoj povas klarigi la originon de solvo, sed ili ne pruvas, ke nuna rulejo havas la saman cimon. Notu la version de la rulejo kaj la eligon de la elektilo antaŭ ol ŝanĝi agordojn de la operaciumo por ĉiu aplikaĵo.

Se la aplikaĵo bezonas HTTP-prokurilon por unu kliento, eksplicita prokurila agordo povas klarigi tiun postulon. Se ĝi bezonas centran aŭtomatan vojigon, esploru, kial la elektilo ricevis aŭ redonis la neatenditan SOCKS-eron.

Propra elektilo devus konservi intencajn preterpasojn kaj fiaskan traktadon. Filtri ĉiun SOCKS-kandidaton sendistinge povas rompi konektojn, kiuj devis uzi unu. Riparu la malĝustan regulon kun la plej malgranda amplekso, kiun vi povas identigi.

Rilataj artikoloj