Coloque la negociación SOCKS de Netty antes del protocolo de su aplicación

Ordene un manejador de proxy SOCKS de Netty antes del tráfico de la aplicación y conserve un destino sin resolver cuando se pretende DNS del lado del proxy.

Para un bootstrap/pipeline de Netty existente donde el servidor SOCKS debe resolver el destino:

bootstrap.resolver(NoopAddressResolverGroup.INSTANCE);

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

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

El punto final del proxy es el puerto local 1080; el objetivo de conexión sin resolver es example.com:443. No use la dirección del proxy para ambos roles ni resuelva el nombre antes de que el manejador lo reciba. Para objetivos públicos en una ruta de proxy público permitida, la lista de proxies SOCKS5 suministra candidatos para el punto final del proxy del manejador.

Coloque Socks5ProxyHandler antes de los manejadores que intercambian tráfico de destino. Espere el future de la conexión del proxy, no solo un canal que llegue al listener. Un método o destino rechazado pertenece a esta etapa de configuración.

Para HTTPS, la siguiente capa TLS usa el nombre de host del destino, la verificación y la confianza requeridas—no la identidad del punto final SOCKS. Solo entonces comienza el intercambio HTTP/aplicación.

El fragmento no proporciona bucles de eventos, tipos de canal, manejadores TLS/HTTP ni manejo normal de errores. Elija el constructor SOCKS que coincida con las necesidades de autenticación; un manejador HTTP Basic es otro protocolo.

Use el resolver no-op solo donde este manejador posterior posee la resolución de nombres de host. Otras conexiones pueden necesitar búsqueda local. Mantenga separados la salida del resolver, el future del proxy, TLS y el resultado de la aplicación al diagnosticar un fallo.

Artículos relacionados