HTTP 502 vs 504 오류 차이와 점검 순서: 실전 가이드
502 Bad Gateway와 504 Gateway Timeout의 차이를 명확히 하고, 실무 점검 순서를 통해 빠르게 해결하는 방법을 소개합니다.
HTTP 502 Bad Gateway는 게이트웨이나 프록시 서버가 업스트림 서버로부터 유효하지 않은 응답이나 연결 실패를 받았을 때 발생하는 오류입니다. 반면 504 Gateway Timeout은 업스트림 서버의 응답이 지정된 시간 내에 도착하지 않았을 때 나타납니다. 이 가이드는 두 오류의 차이를 명확히 구분하고, 실무에서 바로 적용할 수 있는 체계적인 점검 순서를 제공합니다.
502와 504, 무엇이 다른가?
502 Bad Gateway is a signal that the gateway/proxy received an invalid response or connection failure from upstream. 이 오류는 클라이언트와 서버 사이에 위치한 게이트웨이(예: Nginx, Cloudflare 로드 밸런서, Kubernetes Ingress)가 상위 서버로부터 정상적인 HTTP 응답을 받지 못했을 때 반환됩니다. 업스트림 서버가 비정상적인 데이터를 전송하거나, 연결을 강제 종료하거나, 애초에 접속 자체가 불가능한 상황이라면 502가 발생합니다. 반면 504 Gateway Timeout은 게이트웨이가 업스트림 서버에 요청을 전달하고 응답을 기다렸지만, 지정된 시간을 초과할 때까지 아무런 응답도 받지 못했을 때 나타납니다. 502 differs from 504: 502 involves invalid responses or connection failures, while 504 is a timeout. 즉, 502는 ‘잘못된 답변’을 받은 것이고, 504는 ‘답변을 아예 못 받은’ 상태로 이해할 수 있습니다. 이 구분은 원인을 추적할 때 핵심적인 단서가 됩니다.
점검 순서로 빠르게 원인 좁히기
아래 네 단계를 순서대로 진행하면 대부분의 502/504 오류를 정확히 진단할 수 있습니다.
-
업스트림 서버 상태 확인: 먼저 게이트웨이 뒤에 있는 서버 자체의 생존 여부를 확인합니다.
systemctl status nginx,docker ps등으로 서비스 프로세스가 실행 중인지 살피고,ss -tlnp | grep 80으로 해당 포트가 열려 있는지 확인합니다. 방화벽 규칙(iptables -L -n,ufw status)을 점검하여 게이트웨이 IP에서 접근이 허용되는지 반드시 확인하세요. 때로는 DNS 리졸브 실패로 인해 업스트림에 연결하지 못할 수도 있습니다.curl -I http://업스트림IP로 직접 응답을 받아보고, HTTP 200 응답이 오는지 확인합니다. 서버는 살아 있지만 응답 시간이 길어지는 경우에는 이후 504로 이어질 수 있으므로, 응답 시간도 함께 측정(curl -w "time_total: %{time_total}\n")해 두는 것이 좋습니다. -
프록시/게이트웨이 설정 검토: 설정 파일에서
proxy_pass지시어의 IP, 포트, 프로토콜을 꼼꼼히 확인합니다. Nginx의 경우proxy_set_header로 전달하는 Host, X-Forwarded-For 등이 올바르지 않으면 업스트림에서 요청을 거부할 수 있습니다. 특히 gRPC 백엔드와 연동할 때는 유의해야 합니다. For gRPC services, NGINX requires grpc_pass instead of proxy_pass to avoid 502. 일반적인 HTTP 프록시 구성을 그대로 적용하면, 업스트림이 반환하는 gRPC 응답을 NGINX가 해석하지 못해 502를 돌려줍니다. 또한 HTTPS 통신이 필요한데 HTTP로 연결하는 경우도 흔한 원인입니다. 이 경우 SSL 인증서 오류 해결 가이드를 참고하여 상호 인증 설정을 점검해 보세요. Cloudflare를 사용 중이라면, Cloudflare DNS 전용 vs 프록시 모드에 따라 달라지는 연결 경로도 재확인해야 합니다. -
타임아웃 값 조정: 504 오류는 대부분 타임아웃 설정에 기인합니다. Nginx의
proxy_read_timeout(기본 60초),proxy_connect_timeout(기본 60초), 그리고 FastCGI나 uWSGI용 전용 타임아웃을 점검합니다. 업스트림 서버가 요청을 처리하는 데 실제로 얼마나 걸리는지curl로 측정한 값과 비교하여 설정이 너무 짧지 않은지 판단합니다. 예를 들어, API 서버가 평균 90초의 응답 시간을 보인다면proxy_read_timeout 120s;로 충분한 버퍼를 둡니다. 하지만 단순히 시간만 늘리는 것은 임시 방편일 뿐, 서버의 처리 속도 자체를 개선하지 않으면 504가 해결되지 않거나, 극단적인 지연으로 사용자 이탈을 부를 수 있습니다. 또한, Cloudflare의 경우 Origin Server 타임아웃이 100초로 제한되므로, 이보다 긴 처리가 필요하다면 회로 차단기 패턴 등 아키텍처 변경을 고려해야 합니다. -
로그 분석: 지금까지 단계로 해결되지 않았다면 로그가 가장 확실한 답을 줍니다. Nginx
error.log에서upstream timed out(504),connect() failed(502),no live upstreams(502) 등의 에러를 찾습니다.access.log에서는$upstream_response_time을 추출하여 어느 요청이 지연되었는지 파악할 수 있습니다. Kubernetes 환경이라면kubectl describe ingress,kubectl logs -l app=myapp으로 인그레스 및 파드 로그를 동시에 확인합니다. 특히readinessProbe가 너무 빨리 성공으로 전환되거나,preStop훅이 없어 종료 중인 파드로 요청이 유입되는지 살펴야 합니다. Cisco WSA에서는log.access또는log.archive에서 “502”, “504”와 함께 TCP RST, SYN/ACK 실패 여부를 검색합니다. 아래 실전 사례에서 WSA 로그를 자세히 다루겠습니다.
실전 사례로 이해하는 502/504
쿠버네티스 롤아웃 중 502 오류
무중단 배포를 목표로 롤링 업데이트를 설계했지만, 트래픽 전환 순간 502가 발생하는 상황은 매우 빈번합니다. 502 can occur during rollout if readinessProbe is inaccurate and preStop drain is missing. 예를 들어 새 파드가 뜨자마자 readinessProbe가 OK를 반환하도록 설정되어 있으면, 내부 애플리케이션이 아직 요청을 받을 준비가 안 된 상태에서 인그레스가 트래픽을 전달합니다. 마찬가지로 종료되는 파드에 preStop을 설정하지 않으면, 컨테이너 종료 명령과 동시에 연결이 강제 리셋되어 게이트웨이가 502를 반환합니다. 해결책은 readinessProbe의 initialDelaySeconds를 충분히 늘리고, preStop에서 sleep 15 등을 추가하여 수명 주기를 안정화하는 것입니다. 소규모 사업자 홈페이지 유지보수 체크리스트의 배포 점검 항목을 참고하면 이런 실수를 예방할 수 있습니다.
WSA 환경에서 502/504 발생 조건
Cisco Web Security Appliance(WSA)를 경유하는 트래픽에서는 오류 진단이 조금 더 구체적입니다. WSA 로그는 TCP 수준에서 어떤 문제가 있었는지 알려주기 때문에, 502와 504의 차이를 곧바로 식별할 수 있습니다.
- 502 오류는 WSA가 웹 서버와의 TCP 연결 설정을 시도했지만 SYN/ACK를 받지 못할 때 발생합니다. 이는 대상 서버가 다운되었거나, IP가 잘못되었거나, 중간 방화벽이 SYN 패킷을 차단하는 상황을 의미합니다.
- 504 오류는 WSA가 웹 서버와의 연결을 종료하는 TCP 재설정(RST)을 수신할 때 발생합니다. TCP 연결은 성공했지만 서버가 특정 이유(예: 과부하, SSL 협상 실패)로 인해 연결을 끊어버린 경우입니다.
- 또한 504 오류는 WSA가 TCP 연결을 설정하고 GET 요청을 전송했지만 HTTP 응답을 받지 못할 때도 발생합니다. 이는 서버가 요청을 수락했지만 처리 중에 멈추거나, 응답을 생성하지 못하는 상황을 나타냅니다.
WSA 환경에서는 이러한 로그 패턴을 tail -f log.access나 grep "502\|504" log.access 명령으로 실시간 확인하며, 위 점검 순서와 병행하면 원인 파악 시간을 크게 단축할 수 있습니다.
참고 자료
- 502 Bad Gateway 오류 분석과 DevOps 모범 사례 — 확인일 2026-07-30
- WSA 문제 해결 가이드 — 확인일 2026-07-30