Docker が公開したポート。プロキシはそこで待ち受けているか
接続が拒否またはリセットされたときは、プロキシコンテナ内のリスナーと Docker のホストポートマッピングの両方を確認します。
公開された Docker ポートはコンテナ内のエンドポイントへの経路を提供するだけで、プロキシを起動するわけでも、そのプロセスが待ち受けるアドレスを変えるわけでもありません。
一般的なブリッジネットワークのマッピングでは、次の三つの値を比較します。
| 経路の部分 | 確認する値 |
|---|---|
| クライアントの入口 | クライアントが接続するホストアドレスと公開ポート |
| 転送先 | マッピングが選ぶコンテナのアドレスとポート |
| サービス | プロキシがコンテナ内で実際にバインドするアドレスとポート |
コンテナ内で 127.0.0.1 にだけバインドされたプロキシは、そのネットワークアドレスへ転送されたトラフィックを受け取れないことがあります。これはホストのループバックにだけホストポートを公開する場合とは異なります。後者は誰がマッピングに到達できるかを制限しますが、コンテナのループバックはマッピングがサービスに到達すること自体を妨げる可能性があります。
想定する配備に合わせて内部リスナーを選びつつ、制限されたホスト公開とプロキシへのアクセスは維持してください。Dockerfile の EXPOSE 宣言はサービスを起動せず、コンテナの起動が成功しても、そのプロセスが転送先で待ち受けていることは証明されません。
失敗した接続がどこまで進むかを追跡します。拒否とリセットはプラットフォームと転送の実装によって異なるため、どちらか一方だけでは設定を特定できません。サービスに到達したら、有効なプロキシの挨拶を確認し、必要な SOCKS バージョン、認証、宛先ポリシーを適用します。到達可能なホストポートだけでは、そうした能力を立証できません。