컨테이너를 다시 빌드한 후 리버스 프록시에서 502 오류가 반환되는 이유

리버스 프록시는 재빌드된 업스트림에 더 이상 유효한 연결을 열 수 없을 때 컨테이너 재빌드 후 502 오류를 반환합니다.

재빌드 과정에서 컨테이너가 교체되거나, 새 주소가 할당되거나, Docker 네트워크가 분리 또는 이름 변경되거나, 노출 포트가 변경되거나, 불완전한 구성이 복원되거나, 애플리케이션이 준비되기 전에 프록시가 시작될 수 있습니다. 올바른 진단은 프록시 오류 로그에서 시작하며, 오류가 일시적으로 사라질 때까지 두 서비스를 재시작하는 대신 프록시에서 컨테이너까지 정확한 업스트림 주소를 추적해야 합니다.

502가 업스트림 연결 실패로 인해 발생했는지 확인하기

영향받는 도메인에 한 번 요청하고 타임스탬프, 프록시 상태, 업스트림 주소, 전체 오류 메시지를 기록합니다. 연결 거부, 호스트를 찾을 수 없음, 시간 초과, 연결 재설정, TLS 핸드셰이크 실패, 잘못된 응답을 구분합니다.

502는 프록시가 사용 가능한 업스트림 응답을 받지 못했다는 의미이지만, 오류 세부 정보에 따라 대상이 존재하지 않는지, 연결할 수 없는지, 수신 대기 중이 아닌지, 잘못된 프로토콜을 사용하는지가 결정됩니다. 최신 NGINX 문제 해결 가이드에 따르면, Docker 컨테이너를 재빌드하면 이름 확인 또는 구성이 새로 고쳐질 때까지 NGINX가 이전 백엔드 주소를 사용하게 될 수 있습니다.

로그에 기록된 업스트림 이름, 주소, 포트, 프로토콜을 사용하여 프록시 호스트 또는 프록시 컨테이너에서 애플리케이션에 직접 요청합니다. 직접 요청도 같은 방식으로 실패한다면 공용 DNS나 인증서를 변경하지 말고 프록시와 컨테이너 사이를 계속 조사합니다.

재빌드 전후의 업스트림 대상 비교하기

재빌드된 컨테이너 이름, 서비스 이름, 내부 IP, 노출 포트, 게시된 포트, 네트워크 별칭, 네트워크 연결을 확인합니다. 이를 프록시 구성 및 마지막으로 정상 작동했던 대상과 비교합니다.

nginx-proxy 관련 이슈에서는 재빌드로 애플리케이션 컨테이너의 IP가 변경되었지만 프록시는 계속 연결할 수 없는 컨테이너 업스트림으로 요청을 전송한 사례를 설명합니다. 공용 도메인은 올바른 상태였고, 변경된 것은 프라이빗 업스트림 식별자뿐이었습니다.

컨테이너 IP보다 안정적인 Compose 서비스 이름 또는 네트워크 별칭을 우선 사용합니다. IP를 의도적으로 고정한 경우에는 재빌드된 서비스가 실제로 해당 IP를 할당받았는지, 다른 컨테이너가 해당 주소를 사용하고 있지 않은지 확인합니다.

프록시와 앱이 여전히 동일한 Docker 네트워크를 공유하는지 확인하기

프록시와 애플리케이션에 연결된 네트워크를 나열하고, 두 서비스가 하나 이상의 사용자 정의 네트워크를 공유하는지 확인합니다. 호스트 포트를 게시했다고 해서 다른 격리된 Docker 네트워크에서 컨테이너 이름에 자동으로 연결할 수 있는 것은 아닙니다.

한 Docker 네트워킹 사례에서는 종속 서비스를 적절한 네트워크로 이동하자 반복되던 502 응답이 즉시 사라졌습니다. 이는 모든 컨테이너가 실행 중인 경우에도 업스트림 경로에 연결할 수 없을 수 있음을 보여 줍니다.

재빌드 후에도 관계가 유지되도록 일회성 명령 대신 Compose를 통해 서비스를 연결합니다. 스택을 다시 생성한 후 프록시 컨테이너 내부에서 DNS 확인 및 업스트림 포트를 테스트합니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

내부 수신 대기 포트와 바인딩 주소 확인하기

애플리케이션이 프록시에서 사용하는 포트와 컨테이너 네트워크에서 접근할 수 있는 주소에서 수신 대기 중인지 확인합니다. 호스트에 게시된 포트와 컨테이너의 내부 수신 대기 포트를 혼동하지 마세요.

앱이 루프백을 벗어나 바인딩된 후에야 프록시가 연결할 수 있습니다. 컨테이너 내부에서 127.0.0.1을 수신 대기하는 서비스는 로컬 상태 확인 명령이 성공하더라도 프록시에서 사용할 수 없습니다.

애플리케이션 로그와 소켓 목록을 확인하고 프록시 컨테이너에서 직접 요청을 한 번 보냅니다. 포트 연결이 거부되면 재시도 횟수나 프록시 시간 초과 시간을 늘리기 전에 앱의 수신 대기 설정 또는 구성을 수정합니다.

컨테이너 시작이 아니라 애플리케이션 준비 상태를 기다리기

재빌드된 컨테이너가 실행 중이어도 마이그레이션, 데이터베이스 복구, 캐시 예열 또는 구성 생성이 진행 중이면 애플리케이션이 요청을 수락하지 못할 수 있습니다. 첫 502 발생 시각을 상태 확인 및 시작 로그와 비교합니다.

Grist 문제 해결 논의에서는 Docker 아키텍처, 환경 설정, 업스트림 준비 상태가 재빌드 후 지속적인 컨테이너 측 502 오류로 이어질 수 있는 방식을 보여 줍니다.

의미 있는 상태 확인을 추가하고, 단순히 프로세스가 존재하는지가 아니라 클라이언트가 필요한 작업을 수행할 수 있을 때까지 프록시 또는 종속 서비스가 기다리도록 설정합니다. 영구적으로 실패한 앱이 단순히 느리게 시작하는 것처럼 보이지 않도록 재시도 횟수를 제한합니다.

프록시 이름 확인을 새로 고치고 안정적인 경로 재구성하기

서비스 이름, 네트워크, 포트, 상태가 올바른지 확인한 후 프록시를 다시 로드하거나 재생성합니다. 프록시가 시작 시에만 이름을 확인한다면 지원되는 런타임 이름 확인 또는 예측 가능한 재시작 순서를 구성합니다.

실패한 컨테이너 종속성 격리에 대한 ZimaSpace 워크플로는 업스트림이 정상 상태를 유지하지 못하고 반복적으로 종료되는 경우에 유용한 관련 진단 방법을 제공합니다.

또 다른 재빌드 후에도 프록시가 서비스 이름을 확인하고, 의도한 내부 포트에 연결하며, 시작 시간을 기다린 뒤 수동으로 IP를 수정하지 않아도 도메인을 제공할 수 있을 때 수리가 완료된 것입니다. 검증이 끝나면 임시 직접 IP 대상과 문서화되지 않은 네트워크 연결을 제거합니다.