Ilagay ang SOCKS Negotiation ng Netty Bago ang Iyong Application Protocol

Para sa umiiral na Netty bootstrap/pipeline kung saan dapat iresolba ng SOCKS server ang destinasyon:

bootstrap.resolver(NoopAddressResolverGroup.INSTANCE);

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

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

Ang endpoint ng proxy ay lokal na port 1080; ang hindi pa nareresolbang target ng koneksyon ay example.com:443. Huwag gamitin ang address ng proxy para sa dalawang papel at huwag iresolba ang pangalan bago ito matanggap ng handler. Para sa mga pampublikong target sa pinapayagang pampublikong ruta ng proxy, ang listahan ng SOCKS5 proxy ay nagbibigay ng mga kandidato para sa endpoint ng proxy ng handler.

Ilagay ang Socks5ProxyHandler bago ang mga handler na nagpapalitan ng trapiko ng destinasyon. Hintayin ang future ng koneksyon ng proxy, hindi lamang isang channel na umabot sa listener. Ang tinanggihang paraan o destinasyon ay kabilang sa yugtong ito ng pag-setup.

Para sa HTTPS, ginagamit ng susunod na layer ng TLS ang hostname ng destinasyon, ang kinakailangang beripikasyon at tiwala—hindi ang pagkakakilanlan ng endpoint ng SOCKS. Pagkatapos lamang nito magsisimula ang palitan ng HTTP/application.

Hindi nagbibigay ang fragment ng event loop, uri ng channel, TLS/HTTP handler o normal na paghawak ng error. Piliin ang SOCKS constructor na umaayon sa mga pangangailangan ng authentication; ang HTTP Basic handler ay ibang protocol.

Gamitin ang no-op resolver lamang kung saan pagmamay-ari ng downstream handler na ito ang pagresolba ng hostname. Maaaring kailanganin ng ibang koneksyon ang lokal na paghahanap. Panatilihing hiwalay ang output ng resolver, future ng proxy, TLS at resulta ng application kapag nag-diagnose ng pagkabigo.