Netty の SOCKS ネゴシエーションをアプリケーション プロトコルの前に置く

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 エンドポイントの identity ではありません。その後に初めて HTTP/アプリケーションの交換が始まります。

この断片はイベント ループ、チャネル型、TLS/HTTP ハンドラ、通常のエラー処理を提供しません。認証要件に合う SOCKS コンストラクタを選んでください。HTTP Basic ハンドラは別のプロトコルです。

no-op リゾルバは、この下流ハンドラがホスト名解決を担う場合にのみ使ってください。他の接続にはローカル検索が必要かもしれません。障害を診断するときは、リゾルバの出力、プロキシ future、TLS、アプリケーションの結果を区別して保持してください。