Netty의 SOCKS 협상을 애플리케이션 프로토콜보다 먼저 두세요

Netty SOCKS 프록시 핸들러를 애플리케이션 트래픽 앞에 배치하고, 프록시 측 DNS가 의도된 경우에는 확인되지 않은 대상을 유지하세요.

SOCKS 서버가 대상을 확인해야 하는 기존 Netty bootstrap/pipeline의 경우:

bootstrap.resolver(NoopAddressResolverGroup.INSTANCE);

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

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

프록시 엔드포인트는 로컬 포트 1080이고, 확인되지 않은 연결 대상은 example.com:443입니다. 프록시 주소를 두 역할 모두에 사용하지 말고 핸들러가 받기 전에 이름을 확인하지 마세요. 허용된 공용 프록시 경로의 공개 대상에는 SOCKS5 프록시 목록이 핸들러의 프록시 엔드포인트 후보를 제공합니다.

Socks5ProxyHandler를 대상 트래픽을 교환하는 핸들러 앞에 두세요. 리스너에 도달한 채널만이 아니라 프록시 연결 future를 기다리세요. 거부된 메서드나 대상은 이 설정 단계에 속합니다.

HTTPS의 경우 다음 TLS 계층은 대상의 호스트 이름, 필요한 검증과 신뢰를 사용합니다—SOCKS 엔드포인트의 정체성이 아닙니다. 그다음에야 HTTP/애플리케이션 교환이 시작됩니다.

이 조각은 이벤트 루프, 채널 유형, TLS/HTTP 핸들러 또는 일반적인 오류 처리를 제공하지 않습니다. 인증 요구에 맞는 SOCKS 생성자를 선택하세요. HTTP Basic 핸들러는 다른 프로토콜입니다.

no-op 리졸버는 이 하위 핸들러가 호스트 이름 확인을 담당하는 경우에만 사용하세요. 다른 연결에는 로컬 조회가 필요할 수 있습니다. 장애를 진단할 때 리졸버 출력, 프록시 future, TLS 및 애플리케이션 결과를 구분해 두세요.

관련 글