504 Gateway Time-outとは？意味・原因と解決方法

504 Gateway Timeoutとは？

504 Gateway Timeoutは、ゲートウェイまたはプロキシとして機能しているサーバーが、アップストリームサーバーから時間内にレスポンスを受信できなかったことを示すHTTPステータスコードです。プロキシはアップストリームのレスポンスを待っていましたが、時間がかかりすぎたため、プロキシは待機を中止してブラウザに504を返しました。

RFC 9110は次のように定義しています。「504（Gateway Timeout）ステータスコードは、サーバーがゲートウェイまたはプロキシとして動作中に、リクエストを完了するためにアクセスする必要があるアップストリームサーバーから時間内にレスポンスを受信できなかったことを示す」（RFC 9110 §15.6.5）。

キーワードはゲートウェイです。504エラーには必ず2つ以上のサーバーが関与しています。接続先のサーバー（プロキシ/ゲートウェイ）と、その背後にあるレスポンスを返せなかったサーバー（アップストリーム/オリジン）です。一般的なプロキシには、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エラーを理解するには、ブラウザとオリジンサーバー間のタイムアウトチェーンを理解する必要があります。一般的なWebリクエストは複数のレイヤーを通過し、各レイヤーにはそれぞれ独自のタイムアウト設定があります。

一般的なリクエストフローは次のとおりです：ブラウザ → 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エラーが表示された場合、問題はそのサーバー側にあり、あなたのデバイスの問題ではありません。ただし、いくつか試せることがあります。

• 1分待ってから再読み込み（リロード）する — 504の多くは、サーバーが混み合っている間だけ発生します。
• 全員にとってダウンしているか確認する — サイトダウンチェッカーは11か所からページを開きます。そこでも504が出るなら、サイト側の問題です。
• 別のネットワークで試す — Wi-Fiではなくモバイルデータで、またはVPNを切って試してください。自分のプロキシやVPNが、タイムアウトしているゲートウェイである可能性もあるためです。
• サイトのステータスページやSNSを確認する — アクセスの多いサイトは、障害情報を投稿していることがよくあります。

対処法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を追加するか、1つのバックエンドだけに適用するならProxyPass / http://backend:8080/ timeout=300を使用してください。

重要：readとsendのタイムアウトは、転送全体の時間ではなく、連続する2回の読み取り（または書き込み）操作の間隔を測るものです。つまり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を呼び出す場合、それらの呼び出しにタイムアウトを追加し、1つの遅いAPIがすべてのリクエストをブロックしないようサーキットブレーカーを実装してください。
• N+1クエリを削減する — ORMが生成するクエリは数百の個別のデータベース呼び出しを行うことがあります。イーガーローディングやバッチクエリを使用してラウンドトリップを減らしてください。

対処法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） — すべてのワーカーが埋まっており、リクエストがキューで待っています。pm.max_childrenを増やすのはRAMに余裕がある場合だけにし、そうでなければワーカーを占有している遅いリクエストを探してください。

"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 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に特化した修正方法を紹介します。

• 遅いプラグインを特定する — すべてのプラグインを無効化し、1つずつ再有効化してください。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ワーカーを1つ占有します。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を監視してください。1つの遅いAPIがすべてのユーザーに504エラーを連鎖させないよう、タイムアウトとサーキットブレーカーを追加してください。