Docker가 포트를 게시했습니다. 프록시가 거기서 수신 중일까요?
연결이 거부되거나 재설정될 때 프록시 컨테이너 내부의 리스너와 Docker의 호스트 포트 매핑을 모두 확인하세요.
게시된 Docker 포트는 컨테이너 엔드포인트로 가는 경로를 제공할 뿐, 프록시를 시작하지도 않고 그 프로세스가 수신하는 주소를 바꾸지도 않습니다.
일반적인 브리지 네트워크 매핑에서는 다음 세 값을 비교하세요.
| 경로의 부분 | 확인할 값 |
|---|---|
| 클라이언트 진입점 | 클라이언트가 접속하는 호스트 주소와 게시된 포트 |
| 전달 대상 | 매핑이 선택하는 컨테이너 주소와 포트 |
| 서비스 | 프록시가 컨테이너 내부에서 실제로 바인딩하는 주소와 포트 |
컨테이너 내부에서 127.0.0.1에만 바인딩된 프록시는 네트워크 주소로 전달된 트래픽을 받지 못할 수 있습니다. 이는 호스트 루프백에만 호스트 포트를 게시하는 것과 다릅니다. 후자는 누가 매핑에 도달할 수 있는지를 제한하지만, 컨테이너 루프백은 매핑이 서비스에 도달하는 것 자체를 막을 수 있습니다.
의도한 배포에 맞는 내부 리스너를 선택하면서 제한된 호스트 게시와 프록시 접근은 유지하세요. Dockerfile의 EXPOSE 선언은 서비스를 시작하지 않으며, 컨테이너가 정상적으로 시작되었다고 해서 프로세스가 전달 대상에서 수신 중이라는 것이 증명되지는 않습니다.
실패한 연결이 어디까지 진행되는지 추적하세요. 거부와 재설정은 플랫폼과 전달 구현에 따라 달라지므로 어느 하나만으로 설정을 특정할 수 없습니다. 서비스에 도달하면 유효한 프록시 인사말을 확인하고 필요한 SOCKS 버전, 인증, 대상 정책을 적용하세요. 도달 가능한 호스트 포트만으로는 그런 능력을 입증할 수 없습니다.