504 에러 원인과 해결 방법 (504 Gateway Time-out)

504 Gateway Timeout이란?

504 Gateway Timeout은 게이트웨이 또는 프록시 역할을 하는 서버가 업스트림 서버로부터 제시간에 응답을 받지 못했음을 나타내는 HTTP 상태 코드입니다. 프록시가 업스트림의 응답을 기다렸지만, 너무 오래 걸려서 프록시가 대기를 포기하고 브라우저에 504를 반환한 것입니다.

RFC 9110은 504를 이렇게 정의합니다. "504(Gateway Timeout) 상태 코드는 서버가 게이트웨이 또는 프록시로 동작하는 동안, 요청을 완료하기 위해 접근해야 하는 업스트림 서버로부터 제시간에 응답을 받지 못했음을 나타낸다"(RFC 9110 §15.6.5).

핵심 단어는 게이트웨이입니다. 504에는 항상 최소 두 개의 서버가 관련됩니다. 여러분이 접속한 서버(프록시/게이트웨이)와 그 뒤에 있는 응답하지 못한 서버(업스트림/오리진)입니다. 일반적인 프록시에는 Nginx 리버스 프록시, Cloudflare, AWS Application Load Balancer(ALB), CloudFront 등이 있습니다.

504 오류의 표시 형태

어느 계층이 기다리다 포기했는지에 따라 문구가 다릅니다:

• 504 Gateway Time-out, 아래에 "nginx" 표시 — nginx(하이픈을 넣어 Time-out으로 씁니다)
• 504 Gateway Time-out · The server didn't respond in time. — HAProxy의 기본 페이지
• Gateway Timeout · The gateway did not receive a timely response from the upstream server or application. — PHP-FPM 앞에 있는 Apache(mod_proxy_fcgi). HTTP 백엔드를 프록시하는 Apache는 대신 Proxy Error · Error reading from remote server(502)를 표시합니다.
• ERROR · The request could not be satisfied · 504 ERROR — Amazon CloudFront
• Error 524: A timeout occurred — Cloudflare의 버전: 서버에 연결은 됐지만 응답이 제시간에 도착하지 않은 경우입니다
• 페이지가 작동하지 않습니다. · example.com에서 응답하는 데 시간이 너무 오래 걸립니다. · HTTP ERROR 504 — 504 응답에 자체 페이지가 없을 때의 Chrome

문구가 무엇이든 원인은 같습니다. 프록시가 뒤쪽 서버를 기다렸지만 답이 제시간에 오지 않은 것입니다. (Chrome은 브라우저가 아예 연결하지 못했을 때도 같은 "응답하는 데 시간이 너무 오래 걸립니다" 문구를 쓰지만, 그때는 제목이 "사이트에 연결할 수 없음"이고 코드도 HTTP ERROR 504가 아니라 ERR_CONNECTION_TIMED_OUT입니다. ERR_CONNECTION_TIMED_OUT 가이드를 참고하세요.)

504 Gateway Timeout이 발생하는 과정

504 오류를 이해하려면 브라우저와 오리진 서버 사이의 타임아웃 체인을 이해해야 합니다. 일반적인 웹 요청은 여러 레이어를 거치며, 각 레이어에는 자체적인 타임아웃 설정이 있습니다.

일반적인 요청 흐름: 브라우저 → CDN(Cloudflare) → 로드 밸런서 → Nginx → PHP-FPM → 데이터베이스. 데이터베이스 쿼리가 90초 걸리는데 nginx의 fastcgi_read_timeout이 60초라면, nginx는 대기를 멈추고 로드 밸런서에 504를 반환하며, 이 응답은 CDN을 거쳐 브라우저로 돌아옵니다.

504를 반환하는 서버는 대개 애플리케이션 자체가 아니라 중간에 있는 프록시입니다. 애플리케이션은 아직 요청을 처리하고 있을 수도 있고, 멈춰 있을 수도 있습니다.

출처: Cloudflare 524, CloudFront 오리진 설정, Google Cloud, 그리고 각 서버의 문서. PHP 자체의 max_execution_time(30초)은 504를 만들지 않습니다. 이 제한에 걸린 스크립트는 치명적 오류(fatal error)로 멈추고, 이는 500으로 나타납니다. 또한 Linux에서는 데이터베이스나 기타 I/O를 기다리는 시간을 세지 않으므로, 느린 쿼리에 묶인 스크립트는 이 제한보다 훨씬 오래 실행될 수 있습니다.

504 Gateway Timeout의 주요 원인

프록시가 기다리다 포기하는 흔한 이유는 다음과 같습니다:

• 느린 요청 — 무거운 데이터베이스 쿼리, 보고서 생성, 느린 서드파티 API 호출이 프록시의 타임아웃보다 오래 걸립니다.
• 과부하된 서버 — CPU 100%, 메모리 부족, 또는 모든 PHP-FPM 워커가 바빠서 새 요청이 큐에서 기다리는 사이에 프록시가 포기합니다.
• 데이터베이스 병목 — 느린 쿼리, 인덱스 누락, 테이블 잠금, 고갈된 커넥션 풀.
• 너무 짧은 타임아웃 — 원래 오래 걸리는 작업(내보내기, 가져오기, 큰 업로드)을 처리하는 백엔드에는 nginx의 60초가 너무 짧습니다.
• 프록시와 오리진 사이의 네트워크 문제 — 패킷 손실, 또는 프록시의 패킷을 조용히 버리는 방화벽(패킷을 거부하는 방화벽이라면 502가 납니다).
• CDN의 고정 제한 — Cloudflare는 Free, Pro, Business 플랜에서 nginx 설정과 관계없이 125초를 기다린 뒤 Error 524를 표시합니다.
• 트래픽 폭주 — 트래픽 급증이나 공격이 워커를 붙잡아 일반 요청에 제시간에 응답하지 못합니다. (과부하 상태를 스스로 아는 서버는 대신 503으로 응답할 수 있습니다.)

방문자를 위한 504 오류 해결 방법

다른 사람의 웹사이트에서 504 오류가 표시된다면, 문제는 해당 서버 쪽에 있으며 여러분의 기기 문제가 아닙니다. 하지만 몇 가지 시도해 볼 수 있는 방법이 있습니다.

• 1분 기다렸다가 새로고침 — 많은 504는 서버가 바쁜 순간에만 잠깐 나타납니다.
• 모두에게 다운되었는지 확인 — 사이트 접속 확인은 11개 지역에서 페이지를 열어 봅니다. 그곳에서도 504가 나오면 사이트 문제입니다.
• 다른 네트워크로 시도 — Wi-Fi 대신 모바일 데이터를 쓰거나 VPN을 끄고 접속해 보세요. 내가 쓰는 프록시나 VPN이 시간 초과를 낸 게이트웨이일 수도 있습니다.
• 사이트의 상태 페이지나 소셜 계정 확인 — 방문자가 많은 사이트는 장애 소식을 올리는 경우가 많습니다.

해결 방법 1: 타임아웃 설정 늘리기 (Nginx & Apache)

504 오류의 가장 일반적인 해결 방법은 리버스 프록시의 타임아웃 값을 늘리는 것입니다. 백엔드 작업이 원래 기본값인 60초보다 오래 걸린다면, 프록시가 더 오래 기다리도록 설정해야 합니다.

# nginx — reverse proxy to a backend (Node.js, Python, etc.)
location / {
    proxy_pass http://backend;
    proxy_read_timeout 300;
    proxy_send_timeout 300;
}

# nginx — FastCGI (PHP-FPM)
location ~ \.php$ {
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_read_timeout 300;
    fastcgi_send_timeout 300;
    include fastcgi_params;
}

# Leave proxy_connect_timeout / fastcgi_connect_timeout at their defaults:
# nginx caps them at about 75 seconds, and a dead backend should fail fast.

Apache에서는 VirtualHost에 ProxyTimeout 300을 추가하거나, 백엔드 하나에만 적용하려면 ProxyPass / http://backend:8080/ timeout=300을 사용하세요.

중요: read 및 send 타임아웃은 전체 전송 시간이 아니라 연속된 두 읽기 또는 쓰기 작업 사이의 간격을 잽니다. 따라서 proxy_read_timeout 300은 "전체 응답이 300초 안에 끝나야 한다"가 아니라 "300초 동안 데이터가 오지 않으면"이라는 뜻입니다. 값을 바꾼 뒤에는 다시 로드하세요: sudo nginx -t && sudo systemctl reload nginx.

CDN 뒤에 있다면 CDN 자체의 제한이 그대로 적용됩니다. Cloudflare는 125초(Free~Business), CloudFront는 기본 30초에서 끊으므로, nginx 값을 그보다 올려도 CDN을 거쳐 들어오는 방문자에게는 달라지는 것이 없습니다.

해결 방법 2: 느린 스크립트와 데이터베이스 쿼리 최적화

백엔드가 지속적으로 타임아웃을 초과한다면, 타임아웃 값을 늘리는 것은 문제를 감추는 것에 불과합니다. 진정한 해결책은 백엔드 응답 속도를 높이는 것입니다.

• 느린 쿼리 찾기 — MySQL 슬로우 쿼리 로그를 활성화하고(slow_query_log = 1, long_query_time = 1), 의심되는 쿼리에 EXPLAIN ANALYZE를 사용하세요. 누락된 인덱스를 추가하고, SELECT *를 피하고, 큰 결과 세트를 페이지네이션하세요.
• 캐싱 추가 — Redis 또는 Memcached를 사용하여 비용이 큰 쿼리 결과를 캐싱하세요. 매번 페이지 로드마다 5초 걸리는 쿼리는 캐싱해야 합니다.
• 무거운 작업을 백그라운드 작업으로 이동 — 보고서 생성, 이메일 발송, 이미지 처리, 데이터 가져오기는 작업 큐(Celery, Sidekiq, Bull)에서 실행하고, HTTP 요청 사이클 내에서 수행하지 마세요.
• API 호출 최적화 — 백엔드가 느린 서드파티 API를 호출하는 경우, 해당 호출에 타임아웃을 추가하고 하나의 느린 API가 모든 요청을 차단하지 않도록 서킷 브레이커를 구현하세요.
• N+1 쿼리 줄이기 — ORM이 생성하는 쿼리는 수백 개의 개별 데이터베이스 호출을 만들 수 있습니다. 즉시 로딩(Eager loading) 또는 배치 쿼리를 사용하여 라운드 트립을 줄이세요.

해결 방법 3: 서버 리소스 확인 (CPU, RAM, 디스크)

오리진 서버가 과부하 상태이면 요청을 충분히 빠르게 처리할 수 없고, 프록시가 대기하다 타임아웃됩니다. 무엇이 리소스를 소모하고 있는지 확인하세요.

# Check CPU and memory usage
top -bn1 | head -20

# Check disk space (full disk = silent failures)
df -h

# Check memory details
free -m

# Find processes using the most CPU
ps aux --sort=-%cpu | head -10

# Find processes using the most memory
ps aux --sort=-%mem | head -10

# Check active network connections
ss -s

CPU 또는 RAM이 90% 이상이라면 애플리케이션을 최적화하거나, 폭주하는 프로세스를 종료하거나, 서버를 업그레이드해야 합니다. 디스크 공간이 가득 찼다면 오래된 로그 파일, 백업, 임시 파일을 정리하세요. 디스크가 가득 차면 데이터베이스가 조용히 크래시되어 연쇄적인 504 오류를 유발할 수 있습니다.

해결 방법 4: 오류 로그 확인

오류 로그는 프록시가 504를 반환한 정확한 이유를 알려줍니다. 원인을 추측하기 전에 항상 로그를 먼저 확인하세요.

# Nginx error log (look for "upstream timed out")
tail -50 /var/log/nginx/error.log

# Apache error log
tail -50 /var/log/apache2/error.log       # Debian/Ubuntu
tail -50 /var/log/httpd/error_log          # CentOS/RHEL

# PHP-FPM log
tail -50 /var/log/php8.3-fpm.log

# System log (OOM kills, crashes)
tail -50 /var/log/syslog

504 뒤에 자주 보이는 로그 메시지:

"upstream timed out (110: Connection timed out) while reading response header from upstream" (nginx) — 백엔드가 proxy_read_timeout(또는 fastcgi_read_timeout)보다 오래 걸렸습니다. 백엔드를 빠르게 하거나, 그만큼 기다려야 하는 작업이라면 타임아웃을 늘리세요.

"upstream timed out (110: Connection timed out) while connecting to upstream" (nginx) — nginx가 제시간에 연결조차 하지 못했습니다. 패킷을 버리는 방화벽이나, 연결을 받아 줄 여유가 없을 만큼 바쁜 백엔드가 원인입니다.

"server reached pm.max_children setting" (PHP-FPM) — 모든 워커가 바빠서 요청이 큐에서 기다립니다. RAM에 여유가 있을 때만 pm.max_children을 올리고, 그렇지 않다면 워커를 붙잡고 있는 느린 요청을 찾으세요.

"Too many connections" (MySQL) — 연결 한도가 다 찼습니다. 새 연결은 즉시 실패하지만(WordPress의 "Error establishing a database connection" 같은 500), 연결을 붙잡고 있는 쿼리가 504의 원인인 느린 쿼리인 경우가 많습니다.

해결 방법 5: PHP-FPM 설정 조정

PHP 앱(WordPress, Laravel, Magento)에서는 타임아웃을 사슬처럼 맞추세요. 각 계층이 그 뒤의 계층보다 조금 더 길어야 합니다: nginx의 fastcgi_read_timeout ≥ PHP-FPM의 request_terminate_timeout ≥ PHP의 max_execution_time.

PHP-FPM 설정을 바꾼 뒤에는 재시작하세요(sudo systemctl restart php8.3-fpm, 버전은 환경에 맞게). nginx의 fastcgi_read_timeout이 PHP의 제한보다 짧으면 nginx가 먼저 포기하므로, PHP가 아직 작업 중인데도 방문자는 504를 보게 됩니다.

해결 방법 6: CDN 및 프록시 설정 확인

사이트가 Cloudflare나 AWS CloudFront 같은 CDN 뒤에 있다면, CDN에는 서버 설정을 재정의할 수 있는 자체 타임아웃 설정이 있습니다.

Cloudflare: Free, Pro, Business 플랜에서는 오리진이 125초 안에 응답을 시작하지 않으면 Cloudflare가 포기하고 Error 524를 표시합니다(Cloudflare). Cloudflare가 권하는 방법은 요청을 빠르게 만들거나, 오래 걸리는 작업을 백그라운드로 옮기거나, DNS 전용(DNS only, 회색 구름) 하위 도메인에서 제공하는 것입니다. Enterprise 플랜은 제한을 늘릴 수 있습니다.

CloudFront: 배포의 오리진 설정에서 오리진의 응답 제한 시간을 늘리세요(AWS). AWS는 느린 오리진부터 고치라고 권합니다. GET과 HEAD 요청이라면 CloudFront가 오리진에 재시도하므로(기본 3회 연결 시도), 방문자가 504를 받기 전에 오리진은 같은 요청을 여러 번 받을 수 있습니다.

어느 계층이 504를 보냈는지 보려면 HTTP 헤더 검사로 응답 헤더를 확인하세요. server: awselb/2.0은 AWS 로드 밸런서, x-cache: Error from cloudfront는 CloudFront, server: nginx는 nginx입니다. Cloudflare 뒤에서는 모든 응답이 server: cloudflare이므로, 그때는 코드 자체(524인지 504인지)가 단서입니다.

해결 방법 7: WordPress 전용 솔루션

WordPress 사이트는 무거운 플러그인, 데이터베이스 비대화, 공유 호스팅 제한으로 인해 504 오류가 특히 발생하기 쉽습니다. WordPress에 특화된 해결 방법을 소개합니다.

• 느린 플러그인 찾기 — 모든 플러그인을 비활성화한 후 하나씩 다시 활성화하세요. wp-admin에 접근할 수 없으면 SSH를 통해 plugins 폴더 이름을 변경하세요: mv wp-content/plugins wp-content/plugins_disabled. Query Monitor 플러그인을 사용하여 느린 데이터베이스 쿼리를 식별하세요.
• 캐싱 플러그인 설치 — WP Super Cache, W3 Total Cache 또는 WP Rocket은 매 요청마다 PHP를 실행하는 대신 정적 HTML을 제공하여 서버 측 처리를 줄입니다.
• 오브젝트 캐싱 사용 — Redis 또는 Memcached와 WordPress 오브젝트 캐시 플러그인을 설치하세요. 데이터베이스 쿼리 결과를 메모리에 캐싱하여 MySQL 부하를 줄입니다.
• 데이터베이스 정리 — 오래된 게시물 수정본, 트랜지언트, 스팸 댓글, 고아 메타데이터를 삭제하세요. WP-Optimize 또는 WP-Sweep을 사용하세요. wp-config.php에 define('WP_POST_REVISIONS', 5);를 추가하여 향후 수정본 수를 제한하세요.
• wp-cron을 실제 cron 작업으로 옮기기 — 페이지 방문이 WP-Cron을 깨우고, WP-Cron은 예정된 작업을 루프백 요청으로 실행하는데 이 요청이 PHP 워커 하나를 따로 차지합니다. wp-config.php에 define('DISABLE_WP_CRON', true);를 추가한 뒤, 서버가 5분마다 wp cron event run --due-now를 실행하도록 하세요.

504 vs 502 vs 503 vs 408: 차이점은?

이러한 HTTP 오류 코드는 종종 혼동됩니다. 각각의 정확한 의미를 알아보겠습니다.

핵심 차이: 502는 프록시가 깨진 응답을 받았거나 연결이 거부되거나 끊긴 것이고, 504는 업스트림이 아무 응답도 하지 않는 동안 프록시의 타이머가 다 된 것입니다. 503은 프록시가 필요 없으며, 과부하 시 어떤 서버든 보낼 수 있습니다. 408은 클라이언트 측 타임아웃(4xx 클래스)으로, 서버가 클라이언트를 기다리다 포기한 경우입니다.

502와 504가 함께 보인다면 백엔드가 힘겨워하고 있을 가능성이 큽니다. 시간 초과된 요청은 504를, 크래시하거나 강제 종료된 워커는 502를 냅니다.

504가 아니라 502가 보인다면, 502 Bad Gateway 가이드에서 그 원인을 알려 주는 nginx 오류 로그 메시지를 이 사이트의 실제 사례와 함께 설명합니다.

504 오류가 SEO에 미치는 영향

Google 문서는 5xx 오류가 미치는 영향을 이렇게 설명합니다(Google 크롤러 문서):

• 서버 오류를 반환하는 URL 수에 비례해 사이트 전체의 크롤링이 느려집니다.
• 색인된 페이지는 처음에는 유지되지만, 계속 서버 오류를 반환하는 URL은 결국 색인에서 삭제됩니다.
• 서버가 다시 2xx로 응답하면 크롤링은 점차 회복됩니다.

504 Gateway Timeout을 예방하는 방법

예방이 사후 대응보다 항상 낫습니다. 타임아웃 제한 내에서 서버를 안정적으로 운영하기 위한 모범 사례를 소개합니다.

• 모니터링 설정 — 몇 분마다 주요 페이지를 불러오는 가동 시간 모니터가 사용자가 알리기 전에 504를 잡아냅니다.
• 타임아웃 체인 일치시키기 — CDN 타임아웃 ≥ 프록시 타임아웃 ≥ 애플리케이션 타임아웃이 되도록 하세요. 불일치한 값은 예측할 수 없는 504 오류를 유발합니다.
• 헬스 체크 구현 — 로드 밸런서와 프록시는 업스트림 서버를 헬스 체크하고, 응답하지 않는 인스턴스에서 트래픽을 우회시켜야 합니다.
• 캐싱을 적극 활용 — 정적 자산, API 응답, 데이터베이스 쿼리를 캐싱하세요. 캐시된 응답은 504를 유발할 만큼 느려지지 않습니다.
• 오토스케일링 적용 — 수평 확장(인스턴스 추가)을 사용하여 트래픽 급증이 단일 서버를 압도하지 않도록 하세요.
• 무거운 작업 오프로드 — 파일 처리, 보고서 생성, 이메일 발송, 대량 가져오기는 백그라운드 작업 큐로 이동하세요. HTTP 요청 내에서 비용이 큰 작업을 수행하지 마세요.
• 느린 쿼리 모니터링 — MySQL/PostgreSQL에서 슬로우 쿼리 로깅을 활성화하세요. 1초를 초과하는 쿼리에 대해 알림을 설정하세요.
• 의존성 건전성 유지 — 백엔드가 의존하는 서드파티 API를 모니터링하세요. 하나의 느린 API가 모든 사용자에게 504 오류를 연쇄적으로 유발하지 않도록 타임아웃과 서킷 브레이커를 추가하세요.