Docker 브리지 컨테이너에서 호스트 프록시에 접근하기

컨테이너에서 도달할 수 있는 프록시 주소를 고르고 공개 엔드포인트와 Docker 호스트에서 실행되는 프록시를 구분합니다.

일반 브리지 네트워크 컨테이너에서 127.0.0.1은 컨테이너 자신의 루프백 주소입니다. 노트북 localhost에서 수신하는 프록시가 모든 컨테이너 안에서도 자동으로 수신하는 것은 아닙니다.

같은 프록시 URL이 호스트 터미널에서는 작동하고 컨테이너에서는 연결 거부가 나는 이유입니다. 그 주소는 각 환경에서 서로 다른 네트워크 엔드포인트를 가리킵니다.

공개 프록시는 직접 사용할 수 있습니다

서비스나 HTTP 프록시 목록에서 고른 엔드포인트가 실제로 접근 가능한 공인 IP라면 localhost로 바꾸지 말고 그 주소를 애플리케이션에 넘기세요.

docker run --rm \
  -e HTTP_PROXY=http://203.0.113.10:8080 \
  -e HTTPS_PROXY=http://203.0.113.10:8080 \
  your-image

문서용 주소와 이미지를 바꾸세요. 이미지 안 프로그램이 환경 변수를 지원해야 합니다. 변수가 있다고 Docker가 모든 소켓을 프록시 요청으로 바꾸지는 않습니다.

프록시가 Docker 호스트에서 실행되는 경우

Docker Desktop은 호스트 내부 주소에 접근할 host.docker.internal을 제공합니다. 지원되는 네이티브 Engine 구성에서는 호스트 매핑으로 이 관례적 이름을 제공할 수 있습니다.

docker run --rm \
  --add-host host.docker.internal=host-gateway \
  -e HTTP_PROXY=http://host.docker.internal:8080 \
  -e HTTPS_PROXY=http://host.docker.internal:8080 \
  your-image

이는 이름 해석을 바꾸며 포트 포워딩 명령은 아닙니다. 네이티브 Linux에서 호스트 루프백에만 바인딩한 서비스는 호스트 브리지 주소로 여전히 접근할 수 없을 수 있습니다. 리스너, 방화벽과 컨테이너 경로가 연결을 허용해야 합니다. 리스너를 바꾼다면 필요한 클라이언트로 제한하고 인증 없는 열린 프록시를 만들지 마세요.

애플리케이션과 같은 위치에서 테스트하세요

호스트의 curl 결과는 호스트 경로만 시험합니다. 컨테이너 환경에서 요청을 보내 의도한 엔드포인트에 도달하는지 확인하세요.

‘호스트’는 Docker Engine이 실행되는 머신을 뜻하기도 합니다. 원격 Engine이면 노트북과 같지 않을 수 있습니다. 로컬 데스크톱 앱에서 복사한 루프백 IP가 원격 빌더나 서버에서 그대로 작동할 가능성은 특히 낮습니다.

이미지 가져오기 문제는 따로 다루세요. 애플리케이션이 위 환경을 사용하기 전에 데몬이 이미지를 다운로드합니다.

관련 글