Squidのリスナーをバインドできない：まずアドレスを確認する

バインドエラーは、クライアントが目的のリスナーを使う前にプロキシホスト側で発生する。WebサイトのURLやプロキシのパスワードを変更しても、存在しないローカルアドレスが利用可能になるわけではない。

失敗しているエンドポイントを完全に読む。アドレス、ポート、アドレスファミリである。[::1] を含むメッセージは IPv6 loopback に関するものであり、IPv6サイトへ外向きに接続できないこととは異なる。

どのネットワーク名前空間が所有しているかを確認する

コンテナ化されたプロキシなら、コンテナのネットワーク環境内で利用できるアドレスを調べる。そこでの IPv6 サポートとアドレス設定はホストと異なる場合がある。コンテナポートを公開しても、サービスがバインドしようとするすべてのアドレスが自動的に作られるわけではない。

Squid のリスナーに関するリファレンスは、明示的なアドレスが特定のローカルエンドポイントをバインドすると説明している。ホスト名がその環境に存在しないアドレスに解決されると、混乱の原因がさらに増える。

他のバインドエラーには別の原因がある。ポートが使用中なら別のリスナーやインスタンスが考えられる。許可拒否は特権ポートやホストのセキュリティポリシーに関係する場合がある。アドレスが利用不可ならアドレス設定の問題を示す。こうした観察を区別し、すべてのバインド失敗をファイアウォールによる拒否と見なさないこと。

配備が意図的に IPv4 のみなら、意図したアクセスポリシーの下で適切な明示的 IPv4 リスナーを選ぶ。IPv6 が必要なら、その環境を IPv6 対応に設定する。エラーを黙らせるためだけにワイルドカードアドレスへ公開バインドすると、意図以上にプロキシを広く露出させる可能性がある。

最後に、失敗しているソケットがクライアント向けの HTTP リスナーなのか、Squid の別のコンポーネントなのかを確認する。1つの警告ですべてのリスナーが失敗したと証明できないが、無関係なソケットが動作していることも、クライアントが必要とするエンドポイントが利用可能であることを証明しない。