Pon a negociación SOCKS de Netty antes do protocolo da túa aplicación

Para un bootstrap/pipeline de Netty existente onde o servidor SOCKS debe resolver o destino:

bootstrap.resolver(NoopAddressResolverGroup.INSTANCE);

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

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

O punto final do proxy é o porto local 1080; o obxectivo de conexión sen resolver é example.com:443. Non uses o enderezo do proxy para ambos os papeis nin resolvas o nome antes de que o manejador o reciba. Para obxectivos públicos nunha ruta de proxy público permitida, a lista de proxies SOCKS5 fornece candidatos para o punto final do proxy do manejador.

Pon Socks5ProxyHandler antes dos manejadores que intercambian tráfico de destino. Espera o future da conexión do proxy, non só unha canle que chegue ao listener. Un método ou destino rexeitado pertence a esta etapa de configuración.

Para HTTPS, a seguinte capa TLS usa o nome de host do destino, a verificación e a confianza requiridas—non a identidade do punto final SOCKS. Só entón comeza o intercambio HTTP/aplicación.

O fragmento non fornece bucles de eventos, tipos de canle, manejadores TLS/HTTP nin xestión normal de erros. Escolle o construtor SOCKS que coincida coas necesidades de autenticación; un manejador HTTP Basic é outro protocolo.

Usa o resolver no-op só onde este manejador posterior posúe a resolución de nomes de host. Outras conexións poden necesitar busca local. Mantén separados a saída do resolver, o future do proxy, TLS e o resultado da aplicación ao diagnosticar un fallo.