Sæt Nettys SOCKS-forhandling før din applikationsprotokol

Til en eksisterende Netty bootstrap/pipeline, hvor SOCKS-serveren skal opløse destinationen:

bootstrap.resolver(NoopAddressResolverGroup.INSTANCE);

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

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

Proxy-endpointet er lokal port 1080; det uopløste forbindelsesmål er example.com:443. Brug ikke proxy-adressen til begge roller, og opløs ikke navnet, før handleren modtager det. For offentlige mål på en tilladt offentlig proxy-rute leverer SOCKS5-proxylisten kandidater til handlerens proxy-endpoint.

Anbring Socks5ProxyHandler før handlere, der udveksler destinationstrafik. Vent på dens proxy-forbindelses-future, ikke blot en kanal, der når listeneren. En afvist metode eller destination hører til dette opsætningstrin.

For HTTPS bruger det næste TLS-lag destinationens værtsnavn, den krævede verifikation og tillid—ikke SOCKS-endpointets identitet. Først derefter begynder HTTP-/applikationsudvekslingen.

Fragmentet leverer ikke event loops, kanaltyper, TLS/HTTP-handlere eller normal fejlhåndtering. Vælg den SOCKS-konstruktør, der passer til autentificeringsbehovene; en HTTP Basic-handler er en anden protokol.

Brug no-op-resolveren kun, hvor denne nedstrøms handler ejer værtsnavnsopløsningen. Andre forbindelser kan kræve lokal opslag. Hold resolver-output, proxy-future, TLS og applikationsresultat adskilt, når du diagnosticerer en fejl.