Java proxy-hlutur lýsir slóð. Netbiðlarinn ákveður samt hvaða tegundir slóða hann getur notað. Þetta skiptir máli þegar endapunkturinn sem er tiltækur talar SOCKS og forritið notar java.net.http.HttpClient.

Í JDK 25 útfærslunni sem er skoðuð hér tekur beiðnikóði HTTP-biðlarans við HTTP-frambjóðanda frá valinu. SOCKS-frambjóðandi fær hann ekki til að gera SOCKS-samningaviðræður; útfærslan getur haldið áfram án proxy. Því er gott svar ekki næg sönnun þess að SOCKS-færsla sérsniðins vals hafi verið notuð.

Veldu flutninginn fyrst

Fyrir núverandi forrit sem byggir á URLConnection er hægt að gefa samskiptareglu-meðferðinum studdan skýran proxy þegar tengingin er opnuð:

Proxy route = new Proxy(Proxy.Type.SOCKS,
    new InetSocketAddress("proxy.example", 1080));
URLConnection connection = URI.create("https://service.example/")
    .toURL().openConnection(route);
connection.setConnectTimeout(5000);
connection.setReadTimeout(15000);

Fyrir leyfð próf á opinberum skotmörkum skaltu nota samsvarandi SOCKS-endapunkt frá þjónustunni þinni eða af SOCKS-proxylistanum. Þetta er annað biðlara-API, ekki önnur stafsetning á HttpClient.Builder.proxy. Haltu áfangastaðar-URL-inu svo HTTPS haldi áfram að bera kennsl á fyrirhugaða vefsíðu.

Forrit sem verður að halda java.net.http getur í staðinn notað samhæfan HTTP-proxy-endapunkt, þar á meðal samþykktan millistykki sem sér um SOCKS-tenginguna sem fer áfram. Það bætir við raunverulegum hluta og annarri aðgangsmörk; að breyta porti 8080 í 1080 veitir ekki þessa þýðingu.

Haltu vali og upptöku sýnilegum

Skráðu bæði niðurstöðu valsins og tenginguna sem biðlarinn opnar í raun. Sú fyrri lýsir stefnuúttaki; sú seinni staðfestir hvort útfærslan tók hana upp.

Bindu niðurstöður við keyrsluumhverfið og flutninginn sem er notaður. JVM SOCKS-eiginleikar sem ein socket-útfærsla notar eru ekki loforð um að sérhvert HTTP-safn leiti til þeirra. Þegar slóðin er skilyrðislaus ætti að greina óstudda proxy-tegund áður en tekið er við beiðni sem virðist heppnast beint.

Tengdir greinar