Objekt proxy v Javě popisuje trasu. Síťový klient stále rozhoduje, které druhy tras může použít. To je důležité, když dostupný koncový bod mluví SOCKS a aplikace používá java.net.http.HttpClient.

Ve zde zkoumané implementaci JDK 25 přijímá kód požadavku HTTP klienta HTTP kandidáta od selektoru. Kandidát SOCKS jej nepřiměje provést vyjednávání SOCKS; implementace může pokračovat bez proxy. Úspěšná odpověď tedy není dostatečným důkazem, že byl použit záznam SOCKS vlastního selektoru.

Nejprve zvolte přenos

U existující aplikace založené na URLConnection lze obsluze protokolu při otevírání spojení předat podporovanou explicitní proxy:

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);

Pro povolené testy veřejných cílů použijte odpovídající koncový bod SOCKS ze své služby nebo ze seznamu SOCKS proxy. Jde o jiné klientské API, ne o alternativní zápis HttpClient.Builder.proxy. Zachovejte cílovou URL, aby HTTPS nadále určovalo zamýšlený web.

Aplikace, která musí zachovat java.net.http, může místo toho použít kompatibilní koncový bod HTTP proxy, včetně schváleného adaptéru, který zajišťuje navazující SOCKS spojení. To přidává skutečnou komponentu a další hranici přístupu; změna portu 8080 na 1080 toto přeložení neposkytuje.

Udržujte volbu i přijetí viditelné

Zaznamenejte jak výsledek selektoru, tak spojení, které klient skutečně otevře. První popisuje výstup politiky; druhé určuje, zda jej implementace přijala.

Spojujte závěry s použitým runtime a přenosem. Vlastnosti JVM SOCKS používané jednou implementací socketu nejsou slibem, že je každá HTTP knihovna konzultuje. Když je trasa povinná, měl by být nepodporovaný typ proxy zjištěn dříve, než přijmeme zdánlivě úspěšný přímý požadavek.

Související články