502/504는 “내 서버가 죽었나?” 싶게 만드는 대표 장애입니다. 하지만 대부분은 원인 범위가 정해져 있어, 순서대로 확인하면 빠르게 복구할 수 있습니다. 본 글은 Cloudflare를 앞단에 두고 Nginx가 오리진(또는 리버스 프록시)인 환경을 기준으로 정리합니다.
1) 먼저 결론: 502/504는 “오리진(내 서버) 연결 실패/지연”부터 봅니다
- Cloudflare 502/504: Cloudflare가 오리진 서버와 통신하지 못하는 상황이 흔합니다.
- Nginx 502: 업스트림(백엔드: WAS, PHP-FPM, API 등) 응답이 비정상/끊김/헤더 문제일 때 자주 발생합니다.
- Nginx 504: 업스트림 응답이 너무 느려 타임아웃으로 끊기는 경우가 많습니다.
2) 10분 체크리스트(이 순서가 핵심입니다)
- 장애 구간 분리: Cloudflare를 잠깐 우회(오리진 직접 접속)해 동일 증상인지 확인합니다.
- Nginx 에러 로그 확인:
/var/log/nginx/error.log에서 “upstream” 관련 메시지를 먼저 봅니다. - 백엔드 상태 확인: WAS/PHP-FPM/컨테이너/DB가 살아있는지, 포트가 열려있는지 확인합니다.
- 타임아웃 설정 확인:
proxy_read_timeout,proxy_connect_timeout등 설정을 점검합니다. - 리소스 병목 확인: CPU, 메모리, 디스크 I/O, 커넥션 수 폭증 여부를 확인합니다.
3) Nginx 로그에서 자주 보이는 문구별 원인
(1) upstream timed out / 504
- 의미: 백엔드가 응답을 늦게 주거나 멈춰 있어 Nginx가 기다리다 끊은 상태입니다.
- 우선 조치: 백엔드 처리시간(쿼리/외부 API 호출/파일 처리)을 줄이거나, 필요한 경우 타임아웃을 조정합니다.
(2) connect() failed / 502
- 의미: Nginx가 업스트림에 연결 자체를 못 하는 상태입니다(프로세스 다운, 포트/소켓 경로 오류, 방화벽 등).
- 우선 조치: 업스트림 프로세스 재기동, 포트/소켓 경로 재확인, 방화벽/보안그룹 정책 확인이 필요합니다.
(3) 헤더/버퍼 관련(대형 헤더, 쿠키 비대화 등)
- 의미: 백엔드가 내려주는 응답 헤더가 크거나(쿠키 과다), 버퍼 정책과 맞지 않아 에러가 날 수 있습니다.
- 우선 조치: 쿠키/헤더 크기를 줄이거나 Nginx의 프록시 버퍼 설정을 점검합니다.
4) “Cloudflare가 문제인가?” 빠른 판별법
- 오리진 직접 접속에서 정상이라면: Cloudflare-오리진 구간(방화벽, SSL, WAF, 레이트리밋)을 의심합니다.
- 오리진 직접 접속도 동일하게 실패하면: 오리진(내 서버/백엔드) 문제일 가능성이 큽니다.
- Cloudflare 오류 페이지에 Ray ID가 함께 표시되면, 해당 요청 추적에 도움이 됩니다.
5) 재발 방지(운영자가 바로 체감하는 것들)
- 헬스체크: 백엔드 상태를 주기적으로 체크해 장애를 빨리 감지합니다.
- 슬로우 로그: 느린 쿼리/느린 API 호출을 기록해 504 원인을 줄입니다.
- 타임아웃 “무작정 증가” 금지: 근본 원인을 해결하지 않으면 대기만 길어지고 장애가 더 커집니다.
- 캐시/큐 도입: 순간 트래픽이 몰릴 때 백엔드를 보호합니다.
FAQ
Q1. 502/504가 “간헐적”으로만 발생합니다
A. 트래픽 스파이크, GC/스레드 고갈, DB 커넥션 부족, 외부 API 지연처럼 “순간 병목”에서 자주 발생합니다. 발생 시점의 CPU/메모리/커넥션/슬로우쿼리 로그를 함께 봐야 합니다.
Q2. 타임아웃만 올리면 해결됩니까?
A. 일부 케이스에서는 임시 완화가 되지만, 근본 원인(느린 쿼리/락/외부 API 지연/리소스 부족)을 못 잡으면 재발합니다.