Put Netty's SOCKS Negotiation Before Your Application Protocol

For an existing Netty bootstrap/pipeline where the SOCKS server should resolve the destination:

bootstrap.resolver(NoopAddressResolverGroup.INSTANCE);

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

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

The proxy endpoint is local port 1080; the unresolved connection target is example.com:443. Do not use the proxy address for both roles or resolve away the name before the handler receives it. For public targets on a permitted public-proxy route, the SOCKS5 proxy list supplies candidates for the handler's proxy endpoint.

Place Socks5ProxyHandler before handlers exchanging destination traffic. Wait for its proxy connection future, not merely a channel reaching the listener. A rejected method or destination belongs to this setup stage.

For HTTPS, the next TLS layer uses the destination hostname, required verification and trust—not the SOCKS endpoint's identity. Only then does the HTTP/application exchange begin.

The fragment does not supply event loops, channel types, TLS/HTTP handlers or normal error handling. Choose the SOCKS constructor matching authentication needs; an HTTP Basic handler is another protocol.

Use the no-op resolver only where this downstream handler owns hostname resolution. Other connections may need local lookup. Keep resolver output, proxy future, TLS and application result distinct when diagnosing a failure.