HTTP 504 Gateway Timeout — 게이트웨이 시간 초과·타임아웃 원인·해결·예방

HTTP 504 Gateway Timeout — 게이트웨이 시간 초과·타임아웃 원인·해결·예방

웹사이트가 한참 빙빙 돌다가 "504 Gateway Timeout"을 띄운다면, 앞단 프록시가 뒤의 업스트림 서버에 요청을 넘기고 답을 기다렸지만 정해진 시간 안에 응답이 오지 않은 것이다. 502가 "답이 깨졌거나 연결이 거부됐다"였다면, 504는 "연결은 됐는데 답이 너무 늦다"이다. 둘은 짝처럼 닮았지만 원인이 다르다.

 

504는 502와 함께 게이트웨이 계열 5xx 오류다. 핵심은 "느림"이다. 업스트림이 느린 쿼리나 무거운 작업으로 제때 응답하지 못하거나, 프록시의 타임아웃이 너무 짧게 잡혀 있을 때 발생한다. 이 글은 504의 의미, 원인, 타임아웃·진단 코드, 단계별 해결, 그리고 502와의 차이까지 정리한다.

HTTP 504 Gateway Timeout

 

이 글의 구성

 

01504 에러 메시지와 의미

02자주 나오는 발생 원인 5가지

03재현 시나리오와 타임아웃·진단 코드

04해결 방법과 단계별 진단

05502 vs 504 비교와 Cloudflare 524

Q&A자주 묻는 질문 5가지

---

01 504 에러 메시지와 의미

504는 HTTP 응답 상태 코드 가운데 5xx, 서버 측 오류로 분류된다. 게이트웨이나 프록시 역할을 하는 서버가 업스트림(상위) 서버에 요청을 전달하고 응답을 기다렸지만, 정해진 시간 안에 받지 못했을 때 반환한다. 핵심은 "연결은 성립했는데, 응답이 시간 안에 오지 않았다"이다.

항목	내용
상태 코드	504
영문 메시지	Gateway Timeout
한글 의미	게이트웨이가 업스트림 응답을 시간 안에 못 받음
분류	5xx 서버 오류
핵심	연결은 됐다 — 응답이 늦었을 뿐(타임아웃)

502와 504를 나란히 두면 차이가 분명해진다. 502는 업스트림이 연결을 거부하거나 깨진 응답을 준 경우이고, 504는 연결은 됐지만 응답이 제한 시간을 넘긴 경우다. 502가 "죽었거나 틀렸다"라면, 504는 "살아 있는데 너무 느리다"이다. 그래서 504의 진단은 "왜 느린가"로 향한다.

핵심 관찰 — 죽은 게 아니라 느린 것

504는 업스트림이 살아서 작업을 하고 있는데 그게 너무 오래 걸린다는 뜻일 때가 많다. 그래서 "왜 안 되나"보다 "무엇이 느린가"를 물어야 한다. 느린 쿼리, 무거운 연산, 외부 API 지연을 먼저 의심하고, 프록시 타임아웃 설정을 함께 본다.

---

02 자주 나오는 발생 원인 5가지

원인 1 — 느린 업스트림 처리

가장 흔하다. 백엔드가 느린 쿼리, 무거운 연산, 대용량 처리로 응답을 제때 못 만들면 504가 난다. 특정 무거운 요청에서만 504가 뜨는 경우가 전형적이다.

원인 2 — 너무 짧은 프록시 타임아웃

프록시의 응답 대기 시간(예: Nginx proxy_read_timeout 기본 60초)이 작업 시간보다 짧으면, 업스트림이 아직 처리 중인데도 프록시가 먼저 포기하고 504를 낸다. 정상 작업이 오래 걸리는 서비스에서 자주 부딪힌다.

원인 3 — 업스트림 과부하·큐 적체

업스트림이 살아 있어도 처리할 요청이 밀려 큐에 쌓이면, 내 요청의 차례가 늦어져 응답이 제때 안 온다. 트래픽이 몰릴 때 간헐적으로 504가 나타나는 이유다.

원인 4 — DB·외부 의존 서비스 지연

앱 자체는 빠른데 DB 슬로우 쿼리, 락 대기, 또는 외부 API 응답이 느리면 그 시간만큼 전체 응답이 늦어진다. 외부 결제·인증·검색 API에 의존하는 페이지에서 흔하다.

원인 5 — 네트워크 지연

프록시와 업스트림이 서로 다른 서버·지역에 있을 때, 둘 사이의 네트워크가 느리거나 패킷 손실이 있으면 응답 왕복이 길어져 504가 날 수 있다. 비교적 드물지만 분산 환경에서 나타난다.

---

03 재현 시나리오와 타임아웃·진단 코드

먼저 504 응답의 모습이다. 프록시가 기다리다 포기하고 내보내는 응답이다.

# 응답 (프록시가 대기 끝에 생성)
HTTP/1.1 504 Gateway Timeout
Server: nginx

Nginx error.log에는 업스트림 타임아웃이 그대로 찍힌다. 타임아웃 관련 설정도 함께 본다.

# ✗ 에러 로그 — 업스트림 응답 시간 초과
upstream timed out (110: Connection timed out) while reading response header from upstream

# Nginx 타임아웃 설정 (기본 각 60초)
proxy_connect_timeout 60s;
proxy_send_timeout    60s;
proxy_read_timeout    60s;

진짜 핵심은 "업스트림이 실제로 얼마나 느린가"다. 서버 내부에서 직접 요청해 응답 시간을 측정하고, DB 슬로우 쿼리를 확인한다.

# ✓ 업스트림 응답 시간 측정 (총 소요 시간 출력)
curl -o /dev/null -s -w "time_total: %{{time_total}}s\n" http://127.0.0.1:3000/slow

# DB 슬로우 쿼리 로그에서 오래 걸린 쿼리 확인
# (MySQL 예: slow_query_log 활성화 후 long_query_time 초과 쿼리 추적)

---

04 해결 방법과 단계별 진단

504는 "느림"의 문제다. 그래서 타임아웃을 늘리는 임시 조치와 응답 속도를 줄이는 근본 조치를 구분해야 한다.

의심 영역	해결 방법
느린 쿼리·연산	슬로우 쿼리 튜닝·인덱스 추가, 무거운 연산 최적화
짧은 타임아웃	proxy_read_timeout 등 합리적 상향(임시방편)
무거운 작업	큐·백그라운드로 비동기화, 즉시 응답 후 결과 폴링
과부하	스케일 아웃·캐싱으로 처리량 확보
외부 API	외부 호출에 타임아웃·재시도·캐시 적용

단계별 진단 절차

01서버 내부에서 업스트림에 직접 요청해 응답 시간을 측정한다. 정말 느린지 숫자로 확인한다.

02특정 페이지·요청만 느린지 전체가 느린지 구분한다. 일부면 그 작업·쿼리를, 전체면 과부하·자원을 본다.

03DB 슬로우 쿼리·락 대기, 외부 API 응답 시간을 점검한다. 병목이 어디인지 좁힌다.

04급하면 타임아웃을 합리적으로 늘려 복구하되, 근본 원인(느림)을 반드시 함께 개선한다.

05오래 걸리는 작업은 동기 응답에서 빼내 큐·백그라운드로 처리하도록 구조를 바꾼다.

---

05 502 vs 504 비교와 Cloudflare 524

5xx는 코드로 원인을 좁힌다. 특히 게이트웨이 짝인 502와 504를 정확히 구분하는 게 중요하다.

코드	의미	핵심
502	잘못된 게이트웨이 응답	업스트림 연결 거부·깨진 응답(죽음·설정)
504	게이트웨이 시간 초과	연결은 됐으나 시간 내 무응답(느림)
500	서버 내부 오류	앱 자체의 예기치 않은 예외
524	(Cloudflare) 원본 응답 시간 초과	CDN이 원본을 기다리다 타임아웃

504와 헷갈리는 코드로 Cloudflare의 524가 있다. 524는 표준 HTTP 코드가 아니라 Cloudflare가 자체적으로 쓰는 코드로, CDN이 원본 서버(origin)에 연결은 했지만 제한 시간 안에 응답을 받지 못했을 때 나타난다. 의미는 504와 사실상 같다. 원본 서버의 처리 시간을 줄이거나, 긴 작업을 비동기로 빼는 것이 해법이라는 점도 동일하다.

“

504는 타임아웃을 늘려 숨길 수 있지만, 그건 시계를 늦추는 것일 뿐이다. 진짜 해법은 응답을 빠르게 만드는 것이다.

 

— 502는 연결·응답, 504는 시간(느림)

---

06 자주 묻는 질문 5가지

Q1504는 제 인터넷이 느려서 그런가요?

대개 아닙니다. 504는 서버 측, 그중에서도 프록시 뒤의 업스트림이 제때 응답하지 못한 것입니다. 방문자는 잠시 후 새로고침 정도만 할 수 있고, 근본 해결은 사이트 운영자의 몫입니다.

Q2502와 504는 뭐가 다른가요?

502는 업스트림이 연결을 거부하거나 깨진 응답을 준 경우(죽었거나 설정이 틀림), 504는 연결은 됐지만 시간 안에 응답을 못 준 경우(살아 있는데 느림)입니다. "깨졌다"면 502, "느리다"면 504로 기억하면 쉽습니다.

Q3타임아웃만 늘리면 해결되나요?

임시방편입니다. 타임아웃을 늘리면 504는 잠시 줄지만, 사용자는 더 오래 기다리고 서버 자원은 더 오래 묶입니다. 합리적 범위에서 늘리되, 느린 쿼리·작업을 개선하는 근본 대책을 반드시 함께 해야 합니다.

Q4특정 무거운 작업에서만 504가 떠요.

대용량 처리·리포트 생성·외부 연동처럼 오래 걸리는 작업은 동기 요청-응답으로 처리하면 504가 나기 쉽습니다. 이런 작업은 요청 즉시 접수만 응답하고, 실제 처리는 큐·백그라운드로 돌린 뒤 결과를 따로 받아오는 구조로 바꾸는 것이 정석입니다.

Q5Cloudflare에서 524가 떠요.

524는 Cloudflare 고유 코드로, CDN이 원본 서버 응답을 제한 시간 안에 못 받은 경우입니다. 의미는 504와 거의 같습니다. 원본 서버의 처리 시간을 줄이거나, 긴 작업을 비동기로 분리하는 방향으로 접근하면 됩니다.

---

07 결론

504 Gateway Timeout은 "업스트림이 살아 있는데 너무 느려서 프록시가 기다리다 포기했다"는 신호다. 502가 연결·응답의 문제였다면, 504는 시간의 문제다. 그래서 시선은 늘 "무엇이 느린가"를 향한다.

실무 원칙은 다음과 같다.

 

🔍 먼저 업스트림이 정말 느린지 응답 시간을 숫자로 측정하고, 병목이 쿼리인지 외부 API인지 좁힌다.

⚙️ 타임아웃을 늘리는 건 임시방편일 뿐, 근본은 느린 쿼리·작업을 개선해 응답 자체를 빠르게 만드는 것이다.

🛡 오래 걸리는 작업은 비동기로 빼고, 캐싱·모니터링으로 느려짐을 미리 잡는다.

504 트러블슈팅 체크리스트

01서버 내부에서 업스트림 응답 시간을 직접 측정(curl time_total).

02특정 요청만 느린지 전체가 느린지로 범위 좁히기.

03DB 슬로우 쿼리·락 대기, 외부 API 응답 시간 점검.

04proxy_read_timeout 등 타임아웃을 합리적으로 조정(임시).

05슬로우 쿼리 튜닝·인덱스·캐싱으로 응답 속도 근본 개선.

06오래 걸리는 작업은 큐·백그라운드로 비동기화.

07응답 시간 모니터링·알림으로 느려짐을 사전 감지.

---

본 글은 HTTP 504 Gateway Timeout 에러의 일반적 원인과 해결 방법을 정리한 자료다. 서버·프록시 설정 변경은 운영 환경에 적용하기 전 테스트 환경에서 충분히 검증한다.

 

#504에러 #GatewayTimeout #HTTP504 #HTTP에러 #HTTP상태코드 #게이트웨이시간초과 #타임아웃 #업스트림 #슬로우쿼리 #proxyreadtimeout #Nginx #502와504차이 #Cloudflare524 #웹서버 #트러블슈팅