SERVER ERROR CLINIC
프록시가 상위 서버에서 유효한 응답을 받지 못했습니다. 연결 실패뿐 아니라 앱이 응답 도중 연결을 끊거나 잘못된 응답을 보낸 경우도 포함됩니다.
이 도구는 여러분의 서버에 접속하지 않습니다. 답한 내용만으로 확인할 순서를 정해주는 도구이며, 실제 로그를 대신하지 않습니다.
어느 로그를 볼까 프록시(Nginx·Caddy)의 upstream 오류를 먼저 봅니다. 연결 실패라면 앱 기동·포트를, 응답 중 종료나 잘못된 헤더라면 앱 오류 로그를 이어서 확인합니다.
원인 후보 4개
프록시를 건너뛰고 앱에만 물어봅니다. 이 한 번으로 확인할 곳이 절반으로 줄어듭니다.
서버에서 이 명령을 쳐보고, 아래에서 결과를 골라 주세요.
curl -i --max-time 10 http://127.0.0.1:3000/가장 먼저 확인할 것
프록시는 정상인데 넘겨줄 앱 프로세스가 아예 없습니다. 배포·재시작 직후 가장 흔합니다.
다른 후보가 하나씩 제외되면서 남은 원인입니다.
프로세스가 실제로 살아 있는지 봅니다.
systemctl status <서비스이름> --no-pager || docker compose ps그다음 앱을 다시 띄우고, 시작하자마자 죽는다면 앱 로그의 마지막 줄을 봅니다. 설정값 누락으로 기동에 실패하는 경우가 많습니다.
아니라면 다음
앱은 살아 있는데 프록시가 다른 포트나 다른 주소로 요청을 보내고 있습니다. 설정을 고친 직후에 흔합니다.
프록시가 어느 주소로 넘기도록 적혀 있는지 확인합니다.
grep -rn 'proxy_pass\|reverse_proxy' /etc/nginx /etc/caddy 2>/dev/null그다음 설정에 적힌 포트와 앱이 실제로 듣고 있는 포트를 맞춥니다. 앱이 127.0.0.1에만 바인딩돼 있고 프록시가 다른 컨테이너에 있으면 서로 닿지 못합니다.
소켓이 어디로 연결되는지 보기 →아니라면 다음
프로세스 관리자가 죽은 앱을 계속 되살리는 중입니다. 살아 있는 순간엔 되고 죽은 순간엔 502가 납니다.
재시작이 반복되는지, 죽기 직전에 무엇을 찍었는지 봅니다.
journalctl -u <서비스이름> -n 50 --no-pager그다음 재시작 로그에서 죽기 직전 마지막 줄을 찾습니다. 포트 충돌·설정 누락·의존 서비스 미기동이 대부분입니다.
아니라면 다음
앱은 살아 있지만 대기줄이 꽉 차서 새 연결을 못 받습니다. 이때 프록시는 502나 504로 보고합니다.
대기 중인 연결이 비정상적으로 쌓여 있는지 봅니다.
ss -s | head -5그다음 워커 수와 연결 상한을 올리기 전에, 요청 하나가 왜 오래 걸리는지부터 봅니다. 느린 요청이 원인이면 상한만 올려도 곧 다시 찹니다.
동시 연결이 늘면 생기는 일 →실험을 마쳤다면