Squid가 리스너를 바인드하지 못할 때: 먼저 주소를 확인하세요

바인드 오류는 클라이언트가 의도한 리스너를 사용하기 전에 프록시 호스트에서 발생합니다. 웹사이트 URL이나 프록시 암호를 바꾼다고 해서 존재하지 않는 로컬 주소가 사용 가능해지지는 않습니다.

실패한 엔드포인트 전체를 읽으세요. 주소, 포트, 주소 패밀리입니다. [::1] 이 포함된 메시지는 IPv6 loopback 에 관한 것이며, IPv6 사이트로 외부 연결에 실패하는 것과 다릅니다.

어느 네트워크 네임스페이스가 소유하는지 확인하세요

컨테이너화된 프록시라면 컨테이너의 네트워크 환경에서 사용 가능한 주소를 점검하세요. 그곳의 IPv6 지원과 주소 구성은 호스트와 다를 수 있습니다. 컨테이너 포트를 게시한다고 해서 서비스가 바인드하려는 모든 주소가 자동으로 생성되지는 않습니다.

Squid 리스너 문서는 명시적 주소가 특정 로컬 엔드포인트를 바인드한다고 설명합니다. 호스트 이름이 그 환경에 없는 주소로 확인되면 또 다른 혼란의 원인이 될 수 있습니다.

다른 바인드 오류에는 다른 원인이 있습니다. 포트가 사용 중이면 다른 리스너나 인스턴스를 뜻합니다. 권한 거부는 특권 포트나 호스트 보안 정책과 관련될 수 있습니다. 주소를 사용할 수 없으면 주소 구성 문제를 가리킵니다. 모든 바인드 실패를 방화벽 거부로 취급하지 말고 이런 관찰을 구분해 두세요.

배포가 의도적으로 IPv4 전용이라면 의도한 접근 정책에 맞는 명시적 IPv4 리스너를 선택하세요. IPv6가 필요하다면 그 환경이 지원하도록 구성하세요. 오류를 잠재우려고 공개적으로 wildcard 주소에 바인드하면 프록시가 의도보다 넓게 노출될 수 있습니다.

마지막으로 실패한 소켓이 클라이언트를 향한 HTTP 리스너인지 Squid의 다른 구성 요소인지 확인하세요. 경고 하나로 모든 리스너가 실패했다고 증명할 수는 없지만, 무관한 소켓이 동작한다고 해서 클라이언트가 필요로 하는 엔드포인트가 사용 가능하다는 것도 아닙니다.