Sätt Nettys SOCKS-förhandling före din applikationsprotokoll

Placera en Netty SOCKS-proxyhanterare före applikationstrafiken och bevara en oupplöst destination när DNS på proxy-sidan är avsedd.

För en befintlig Netty bootstrap/pipeline där SOCKS-servern ska lösa destinationen:

bootstrap.resolver(NoopAddressResolverGroup.INSTANCE);

pipeline.addFirst(
    new Socks5ProxyHandler(new InetSocketAddress("127.0.0.1", 1080))
);

bootstrap.connect(
    InetSocketAddress.createUnresolved("example.com", 443)
);

Proxy-slutpunkten är lokal port 1080; det oupplösta anslutningsmålet är example.com:443. Använd inte proxy-adressen för båda rollerna och lös inte upp namnet innan hanteraren tar emot det. För offentliga mål på en tillåten offentlig proxy-rutt tillhandahåller SOCKS5-proxylistan kandidater för hanterarens proxy-slutpunkt.

Placera Socks5ProxyHandler före hanterare som utbyter destinationstrafik. Vänta på dess proxy-anslutnings-future, inte bara en kanal som når lyssnaren. En avvisad metod eller destination hör till detta installationssteg.

För HTTPS använder nästa TLS-lager destinationens värdnamn, den verifiering och det förtroende som krävs—inte SOCKS-slutpunktens identitet. Först då börjar HTTP-/applikationsutbytet.

Fragmentet tillhandahåller inte händelseloopar, kanaltyper, TLS/HTTP-hanterare eller normal felhantering. Välj SOCKS-konstruktorn som matchar autentiseringsbehoven; en HTTP Basic-hanterare är ett annat protokoll.

Använd no-op-resolvern bara där denna nedströms hanterare äger värdnamnsuppslagningen. Andra anslutningar kan behöva lokal sökning. Håll resolver-utdata, proxy-future, TLS och applikationsresultat åtskilda när du diagnostiserar ett fel.

Relaterade artiklar