「504 gateway time-out」が突然表示され、サイトが開かない、APIが失敗する、監視が真っ赤になる——。
このエラーの厄介な点は、原因がアプリそのものとは限らず、CDN・ロードバランサ・Nginxなど“中継点”のどこかが上流の応答を待ちきれずに起きることです。闇雲にタイムアウト値を伸ばしても、根本原因が解消されないまま、別の形で障害が再発してしまうケースも少なくありません。
本記事では、504の基本的な意味を押さえたうえで、CDN/LB/Nginx/アプリ/DBのどこで詰まっているかを最短で特定する切り分け手順を、チェックリストと具体的な観測ポイント付きで解説します。さらに、設定を変更する場合の考え方（伸ばす前に直すべき点、層ごとの整合の取り方）と、性能改善・監視設計・運用フローまで踏み込み、同じトラブルを繰り返さないための道筋をまとめます。
「今すぐ復旧したい」「原因を特定して再発を止めたい」という方は、この順番で確認すれば迷わず前に進めます。
※本コンテンツは「記事制作ポリシー」に基づき、正確かつ信頼性の高い情報提供を心がけております。万が一、内容に誤りや誤解を招く表現がございましたら、お手数ですが「お問い合わせ」よりご一報ください。速やかに確認・修正いたします。
504 gateway time-outとは何か
HTTP 504の意味と起きていること
「504 gateway time-out（504 Gateway Timeout）」は、中継役（ゲートウェイ／プロキシ）が、上流（オリジンサーバやバックエンド）から規定時間内に応答を受け取れなかったときに返されるHTTPステータスです。ポイントは「サーバが落ちている（必ずしもそうではない）」ではなく、“待っている側が待ちきれなかった”という点にあります。
たとえば、次のような経路でリクエストが流れるケースを想像してください。
利用者のブラウザ／アプリ
CDN（例：Cloudflareなど）
ロードバランサ（例：ALB/ELB、NLB、HAProxyなど）
リバースプロキシ（例：Nginx、Apacheなど）
アプリケーション（例：PHP-FPM、Node.js、Java、Pythonなど）
DB／外部API／ストレージ
この経路のどこかで「上流から返事が来ない」「返事が来るまでの間隔が空きすぎる」「接続できない状態が続く」などが起きると、手前の中継点がタイムアウトし、結果として504が表に出ます。つまり504は、本当の原因が“さらに奥”にある可能性が高いエラーです。
よく混同される502/503との違いも整理しておきます。現場では厳密に区別できないこともありますが、理解しておくと切り分けが速くなります。
502 Bad Gateway：中継が上流に接続できても、返ってきた応答が不正・想定外（プロトコル不一致、上流の異常応答など）
503 Service Unavailable：サーバが一時的に処理できない（過負荷、メンテナンス、アプリ停止など）
504 Gateway Timeout：中継が上流応答を待ったが、時間内に受け取れなかった（待ち・遅延・上流停止・経路不通など）
なお、「504が出ている＝アプリが必ず遅い」とは限りません。DNSの名前解決やネットワーク経路の問題、上流のコネクション枯渇、ロードバランサ配下のターゲット不健康、外部APIの遅延など、“遅い／返らない”の原因が多様なのがこのエラーの難しさです。
誰が504を返しているかを見分ける
最初にやるべきことは、どの層（誰）が504を返しているかを可能な範囲で特定することです。これが曖昧なまま設定だけ触ると、対処が散らばって復旧が遅れ、再発率も上がります。
判定の手がかりは主に3つです。
エラーページの見た目（文言やロゴ）
CDN（Cloudflareなど）やロードバランサが独自のエラーページを出す場合があります。特有のID（Ray ID等）が表示されることもあり、層の特定に役立ちます。
ただし、運用側で独自エラーページに置き換えていることもあるため、見た目だけで断定せず次の手がかりも併用します。レスポンスヘッダ（server、via、cf-ray等）
serverなどのヘッダがヒントになることがあります。たとえばserver: cloudflareならエッジ側が応答主体である可能性が上がりますし、server: nginxならオリジン側（またはオリジン前段）が返している可能性が上がります。
ただし、ヘッダは隠される／書き換えられることもあるので、こちらも“傾向”として扱います。ログの所在（どこに痕跡が残るか）
これが最も強力です。
CDNのログ（イベント、エッジ側のエラー）に504が出るか
ロードバランサのアクセスログにターゲット応答時間やステータスが出るか
Nginxのaccess/errorにupstream timeout系が出るか
アプリログにリクエスト開始はあるが完了がない（もしくは極端に遅い）か
DBのスロークエリが同時刻に急増しているか
「誰が返したか」が分かると、次に“どこを掘るか”が決まります。たとえば、CDNが返しているなら「CDN→オリジン到達」や「オリジンの応答遅延」が主戦場ですし、Nginxが返しているなら「Nginx→upstream（アプリ）」「アプリ→DB/外部API」へ焦点が移ります。
504 gateway time-outの原因を全体図でつかむ
発生点は5層に分けると迷いにくい
504は原因のバリエーションが多いので、闇雲に当てに行くのではなく、層（レイヤ）で整理して考えると迷いが減ります。現場で使いやすいのは次の5層です。
CDN／エッジ層
エッジがオリジンへ接続できない、オリジン応答が遅い、WAF/ルールで意図せず遮断、TLSハンドシェイクの問題など。ロードバランサ層
ターゲットが不健康、ヘルスチェック不一致、ターゲット数不足、コネクション数上限、スケール遅延、特定AZ/リージョンの不調など。リバースプロキシ層（Nginx/Apache等）
上流接続タイムアウト、読み取りタイムアウト、DNS解決の遅延、upstreamの枯渇、keepaliveやバッファ設定の影響、ワーカープロセス枯渇など。アプリケーション層
CPU負荷、メモリ不足（GC頻発など）、スレッド／ワーカー枯渇、ロック待ち、重い処理（画像生成、集計、CSV出力）、同期I/O（外部API/ストレージ）待ちなど。DB／外部依存層
スロークエリ、インデックス不足、ロック競合、コネクション枯渇、レプリケーション遅延、外部APIの遅延・障害、ネットワーク不安定など。
この整理の利点は、観測できるデータ（ログ・メトリクス）を層ごとに揃えられることです。
例：Nginxの$upstream_response_timeが跳ねているのにアプリの処理時間が短いなら、Nginxとアプリの間（ネットワークやupstream枯渇）を疑う、といった推理ができます。
よくある原因トップパターン
現場で頻出する原因を、症状と合わせて“型”として覚えておくと初動が速くなります。
特定URLだけ遅い（例：検索、一覧、レポート出力）
ありがち：DBクエリが重い、N+1、ソート＋ページングが重い、JOINの設計が悪い
症状：特定エンドポイントだけ504、ピーク時に顕著
全体が断続的に遅い（スパイクで504）
ありがち：同時アクセス増でワーカー枯渇、キューが伸びる、コネクション上限
症状：一定時間だけ落ちる、夜間バッチやキャンペーン直後に発生
外部API依存が遅い
ありがち：外部APIの遅延、タイムアウト設計不足、リトライ地獄、同期実行
症状：外部連携が絡む画面・APIだけ遅い
デプロイ直後に出始めた
ありがち：DBマイグレーション、キャッシュ不整合、接続先変更、WAF/CDNルール変更
症状：リリース時刻と発生時刻が一致、ロールバックで改善することが多い
上流サーバ不健康（落ちかけ）
ありがち：OOM、ディスク逼迫、CPUスロットリング、GCスパイク
症状：応答が返らない、ヘルスチェック落ち、再起動で一時回復
「何が起きているか」は複合要因になりやすいので、“最初に一番可能性の高い型”を当てに行きつつ、ログで裏取りする進め方が現実的です。
504 gateway time-outの切り分け手順
まず影響範囲と再現条件を固定する
復旧を早める最大のコツは、最初の段階で「現象の枠」を固めることです。原因調査を急ぐあまり、再現条件が曖昧なまま手当たり次第に触ると、何が効いたのか分からなくなり、再発防止も難しくなります。
最低限、次の項目を押さえます。
発生開始時刻：監視アラート、ユーザー報告、ログで一致点を取る
影響範囲：全ページか、特定URLか、特定機能か（例：ログイン後だけ、検索だけ）
発生頻度：常時／断続／ピーク時のみ
発生条件：特定パラメータ、特定ユーザー、特定リージョン、特定ISP
直近変更：デプロイ、設定変更、DB変更、WAF/CDNルール、証明書更新、DNS変更
ここで重要なのは、「特定URLに偏っているか」です。偏っているならアプリ・DB要因の確率が上がります。一方、全体で落ちるならインフラ層（LB/Nginx）や共通依存（DB/外部API）の疑いが上がります。
初動15分チェックリスト
発生開始時刻を確定（監視とログで合わせる）
全体影響か、特定URL影響かを判定
504を返している主体（CDN/LB/Nginx等）の当たりを付ける
直近変更（デプロイ／設定／DB／WAF／DNS）を洗い出す
CPU/メモリ/ディスクI/O/接続数に急変がないか確認
同時刻でNginxログ・アプリログ・DB指標を並べる
CDNとオリジンのどちら側かを切り分ける
CDNを使っている環境では、まず「CDN側が原因なのか」「オリジン（アプリ側）が原因なのか」を分けます。ここが混ざると、オリジンを直してもCDN設定が原因で改善しない、あるいはその逆が起きます。
切り分けの基本は次の3点です。
CDNの状態とイベントを見る
エッジ側でエラーが増えているか、特定POPだけか、WAFルールが発火していないかなどを確認します。外形監視や他地域からのアクセス結果も有用です。（可能なら）オリジン直アクセスで比較する
セキュリティ要件に反しない範囲で、オリジンに直で当てたときの挙動を確認します。直で速いなら、CDN/WAF/経路の可能性が上がります。直でも遅いなら、オリジン側の遅延が濃厚です。キャッシュの差を確認する
キャッシュHITは見えるが、MISSで落ちる／遅い場合、オリジン負荷が高く、動的生成が詰まっている可能性が高いです。逆に、キャッシュに乗るはずの静的コンテンツまで落ちるなら、経路やDNS、TLSなど別の問題も疑います。
Nginx・アプリ・DBをログで突合する
504の切り分けで最も効果があるのは、同時刻でログを突合することです。単独で眺めても分からないことが、並べると一本の線になります。
おすすめの順番は次のとおりです。
手順1：Nginx access.logで「どのURLが」「どれくらい」遅いかを見る
まずは対象URLのアクセスを抽出し、リクエスト時間や上流応答時間が記録されているなら確認します。
Nginxのログ形式に以下のような項目があると特に有効です。
$request_time：受けてから返すまでの総時間$upstream_response_time：上流から応答を受け取るまでの時間$status：最終ステータス$upstream_status：上流から見たステータス
ここで分かること：
特定URLに遅さが集中しているか
504が一部だけか、広く出ているか
上流応答時間が伸びているか（＝上流が遅い/返さない）
手順2：Nginx error.logで「タイムアウトの種類」を見分ける
error.logには、上流に関するエラーが出ます。代表的には「upstream timed out」系です。
ここで重要なのは、接続できないのか、読めないのかを区別することです。
接続系：上流へ繋がらない、DNS解決が遅い
読み取り系：上流は繋がったが、応答が返ってこない／間隔が空く
リセット系：上流が途中で切る、keepaliveの相性
この区別がつくと、「ネットワーク/名前解決/LB」寄りなのか、「アプリ/DB」寄りなのかの当たりが付けられます。
手順3：アプリログ/APMで「処理のどこで詰まっているか」を見る
アプリ側でリクエストの開始・終了、処理時間、例外が見えるなら、同時刻の該当リクエストを追います。
リクエスト開始ログはあるが終了がない：アプリが詰まっている可能性
処理時間が極端に長い：DB/外部API/ロック待ちなどを疑う
タイムアウト例外（外部HTTP呼び出し等）：外部依存が原因の可能性
APMを入れているなら、トレースでDBクエリや外部API呼び出しの時間が見えるので、根因への到達が速いです。
手順4：DBのスロークエリ/ロック/接続数を確認する
DBが原因の504は非常に多いです。次を確認します。
スロークエリが同時刻に増えていないか
ロック待ちが増えていないか
コネクションプールが枯渇していないか
CPU/IOが張り付いていないか
特に「ピーク時だけ発生」するタイプは、DB接続数やロック競合が原因のことが多く、アプリ側のワーカー枯渇と連鎖します。
応急処置の選択肢とリスク
切り分けと同時並行で、ユーザー影響を抑える応急処置も検討します。ただし応急処置は、根治ではなく「被害を広げない」ことが目的です。副作用も理解したうえで選びます。
応急処置の代表例
スケールアウト／スケールアップ
インスタンス数を増やす、CPU/メモリを増やすなどで処理能力を上げます。
ただし、ボトルネックがDBや外部APIの場合は効果が限定的です。むしろ同時アクセスが増えてDBをさらに苦しめることもあります。重いエンドポイントの一時遮断／レート制限
特定URLが原因なら、そこを一時的に制限するのが効きます。
管理画面の重い集計
レポート生成
外部API連携の多い機能
など、全体を巻き込む前に止血できます。
キャッシュ強化／静的化
動的生成を減らしてオリジン負荷を下げます。トップページや一覧など、キャッシュ可能な部分は非常に効果的です。ロールバック／設定切り戻し
直近変更が明確なら、根治よりも切り戻しが最短の復旧策です。
「原因は後で調べる」割り切りが、ユーザー影響を最小化します。再起動（Nginx/アプリ/ワーカー）
詰まりが解消することはありますが、再発しやすいです。再起動で改善した場合も「なぜ詰まったか」をログとメトリクスで追い、根因を残さないことが重要です。
応急処置を選ぶときの注意点チェックリスト
ボトルネックがどこか（アプリ/DB/外部API）を仮説でよいので置いたか
スケールが逆効果にならないか（DB負荷増）を想定したか
“重い機能”を止めても事業影響が許容できるか
ロールバックで戻せる状態か（DB変更の互換性）
施策の前後で指標を比較できるように時刻を記録したか
Nginxなど設定で直す場合の考え方
proxy_read_timeoutなど主要設定の意味
Nginx周りで504対策として語られやすいのがタイムアウト設定です。ただし、タイムアウトは“薬”であり、使い方を誤ると“副作用”で別の障害を生むことがあります。意味を押さえてから調整します。
代表的な項目の考え方は次のとおりです。
proxy_connect_timeout：上流へ接続するまでに待てる時間
上流の枯渇やネットワーク問題があるとここで詰まります。proxy_read_timeout：上流からの応答を読み取る際の待ち時間
重要なのは「総処理時間」ではなく、読み取りの“間隔”が空いたときに切れる性質があることです。上流が長い計算をしていてしばらく無音だと切れやすくなります。proxy_send_timeout：上流へリクエストを送信する際の待ち
大きなリクエスト（ファイルアップロード等）や上流が詰まっていると影響が出ます。
加えて、ロードバランサやCDNにもタイムアウトがあり、層ごとに上限が異なると、手前が先に諦めて504を返し、奥は処理を続ける“無駄撃ち”が発生します。設定は単体ではなく、層全体で整合させるのが重要です。
タイムアウト延長より先に直すべきこと
「504が出る＝タイムアウトを伸ばす」は、短期的には見た目が改善することがあります。しかし、実運用では次の副作用が出やすいです。
遅い処理が長時間居座り、ワーカーや接続を占有する
同時アクセスが増えると待ち行列が伸び、全体が詰まる
結果として、504が減らずに“もっと大きな障害”になる
したがって、タイムアウトを伸ばす前に、遅さの原因を先に潰すほうが再発防止に直結します。優先順位の目安は以下です。
1) どの処理が遅いかを見える化する
特定URLか、全体か
ピーク時だけか、常時か
DBなのか、外部APIなのか、CPUなのか
ここを曖昧にしたまま延長しても、根因が残って再発します。
2) DBが原因ならDBから直す
DBはボトルネックになりやすく、改善効果も大きいです。
スロークエリの上位を最優先で改善
インデックスを適切に張る
トランザクションを短くする
ロック競合を減らす
3) 外部API依存があるならタイムアウトとフォールバックを設計する
外部APIの遅延は自分では制御しづらいので、設計で守ります。
外部呼び出し側のタイムアウトを適切に設定
リトライ回数と間隔を抑える（リトライ地獄を避ける）
キャッシュ・代替データ・サーキットブレーカを検討する
4) 同時実行数を制御する
“遅い処理”が同時に走ると全体が詰まります。
キューイングやワーカー制御、レート制限で、落ちるより“遅延を抑えて返す”設計に寄せます。
5) 非同期化でHTTP同期の呪縛から外す
集計やレポート生成などは、HTTPリクエストの同期で完結させないほうが安定します。
ジョブキューに流し、進捗確認・完了通知でUXを成立させると、504の根本原因を減らせます。
設定を伸ばす前チェックリスト
504が全体か特定URLかを判別した
Nginxログでupstream遅延の有無を確認した
アプリ/APMで遅延箇所（DB/外部API/CPU）を把握した
DBスロークエリとロック待ちを確認した
外部API遅延時の挙動（待ち続ける/失敗する）を把握した
同時実行制御の余地（キュー、レート制限）があるか検討した
延長するなら階層設計で上限を揃える
どうしても延長が必要なケースはあります。たとえば、業務要件として「最大で○秒かかるが同期で返したい」処理がある場合です。その場合は、単体の設定だけを伸ばすのではなく、層ごとの上限を整合させるのが必須です。
“整合が取れていない”と何が起きるかを簡単に言うとこうです。
手前が先に切る → 504が返る
奥は処理を続ける → リソースが無駄に消費される
同時アクセスが来る → さらに詰まる
結果として障害が拡大する
タイムアウト整合チェック表
| 層 | 何を守る上限か | 典型症状 | 整合が崩れると起きること |
|---|---|---|---|
| CDN | エッジ→オリジン待ち | エッジが504を返す | オリジンが無駄に処理を継続 |
| LB | ターゲット待ち | LBが504、ターゲット不健康 | バーストで一気に落ちる |
| Nginx | upstream接続/読み取り | upstream timed out | 接続占有でワーカー枯渇 |
| アプリ | リクエスト処理 | ワーカー/スレッド枯渇 | 全リクエストが渋滞 |
| DB/外部API | 依存先待ち | 返らない・遅い | 連鎖的に遅延が増幅 |
伸ばす場合の現実的な進め方（番号付きステップ）
“同期で返すべき最大時間”を業務要件として決める
何となく伸ばすのではなく「ここまでが許容」という上限を先に決めます。各層の設定を棚卸しする
CDN/LB/Nginx/アプリ/外部APIで、どのタイムアウトが何秒かを一覧にします。上限を揃える（ただし上げすぎない）
手前が先に切れないように合わせますが、上げすぎると滞留が増えるため、同時実行制御もセットで入れます。変更は段階的に行い、指標で確認する
504率、p95/p99レイテンシ、ワーカー使用率、DB接続数などを比較します。延長は暫定と割り切り、根因改善のタスクを確定する
延長で収まったとしても、遅い処理が残っていれば次のピークで再発します。
再発防止のための設計と監視
性能改善の定番（DB/キャッシュ/非同期化）
504を減らす最短ルートは「タイムアウト値の調整」ではなく、遅さ（レイテンシ）そのものを減らすことです。再発防止で特に効果が高い3本柱を整理します。
DB改善（最優先になりやすい）
スロークエリ上位から改善：体感で効く
インデックス最適化：検索や並び替えが重い場合は特に効く
N+1の解消：一覧ページの遅延要因の定番
ロック競合の削減：更新頻度の高いテーブルは設計見直しも検討
コネクション設計：プール枯渇は“待ち”を生み、タイムアウト連鎖を起こします
キャッシュ（負荷を下げる最短手段）
CDNキャッシュ：静的・準静的コンテンツのオリジン負荷を落とす
アプリキャッシュ：よく参照されるデータを短時間でもキャッシュする
クエリ結果キャッシュ：DBが苦しいときの即効性が高い（ただし整合性に注意）
キャッシュは万能ではありませんが、ピーク時の“耐え”を作るのに非常に有効です。
非同期化（HTTP同期を減らす）
レポート生成、集計、外部連携、重い画像処理などはジョブキューへ
同期で返すのは「受付完了」までにして、結果は後で取得する
進捗や完了通知を用意してUXを成立させる
非同期化は開発コストがかかりますが、504の根が深いケースほど効果が大きいです。
監視設計（メトリクスとアラート）
障害対応のスピードを上げるには、ログだけでなくメトリクスの“見方”が重要です。特に504は「発生してから気づく」より「前兆で気づく」ほうが被害を抑えられます。
最低限、次の指標を揃えると戦いやすくなります。
レイテンシ：平均ではなくp95/p99（遅い側）
エラー率：5xx全体と504の割合、URL別の内訳
上流到達率：CDN→オリジン、Nginx→upstreamの成功率
リソース：CPU/メモリ/ディスクI/O、コネクション数、ワーカー数、キュー長
DB：スロークエリ件数、ロック待ち、接続数、CPU/IO
アラートは「504が一定回数以上」だけだと手遅れになりがちです。
p99レイテンシの急上昇
上流到達率の低下
DBロック待ちの増加
ワーカー使用率の張り付き
など、前兆の段階でも鳴るようにすると、結果として504自体を減らせます。
運用フロー（障害時の判断を早くする）
最後に、再発防止は技術だけでは完結しません。実際の運用では、判断の速さが復旧時間に直結します。以下を整備すると、同じ障害でもダメージを小さくできます。
切り分け手順をテンプレ化する
本記事の「初動15分チェックリスト」「ログ突合の順番」をそのまま手順書に落とし込みます。ロールバック基準を決める
例：リリース後○分以内に5xxが○%超えたら戻す、など。迷いが減ります。段階的リリース（カナリア等）を導入する
全体に出す前に小さく出して影響を限定します。ステータス告知のテンプレを用意する
社内・顧客向けの文面を準備しておくと、対応が後手になりません。
504は「原因が奥にある」ことが多い分、初動の型があるだけで復旧が大きく早まります。
504 gateway time-outのよくある質問
閲覧者側でできることはあるか
閲覧者側でできることは限られますが、状況によっては改善することもあります。
まずは再読み込み（一時的な混雑なら復帰することがあります）
時間を置いて再試行（ピークが過ぎると戻る場合があります）
別回線・別端末・別ブラウザ（特定経路の問題を避けられることがあります）
VPN/プロキシの無効化（企業ネットワーク等の経路制約が原因のこともあります）
ただし多くの場合、根本原因はサーバ側（運営側）にあります。閲覧者側でできることは「一時回避」にとどまるため、長引く場合は運営側の復旧を待つのが現実的です。
502と504はどう違うか
実務的にはこう理解しておくと切り分けが進みます。
502：上流から何か返ってきたが、内容が不正・異常で中継が処理できない
504：上流から返ってくるまで待ったが、時間内に返ってこない
502は“応答の異常”、504は“応答の遅延（または不在）”が中心です。
ただし、同じ根因（過負荷など）でも環境によって502になったり504になったりすることがあるため、最終的にはログとメトリクスで見分けるのが確実です。
タイムアウトは何秒にすべきか
一律の正解はありません。決め方の考え方は次の順番が安全です。
ユーザー体験として待てる時間を決める
多くの画面やAPIでは数秒〜十数秒が目安になりやすいです。同期で返すべき処理と、非同期に逃がすべき処理を分ける
重い処理を同期で返そうとすると、504だけでなくシステム全体の耐久性が落ちます。層ごとに整合を取る
CDN/LB/Nginx/アプリ/外部APIで、手前が先に切れないように揃えます。延長するなら同時実行制御もセットで導入する
延長で滞留が増えるなら、別の障害（接続枯渇など）に形を変えて再発します。
Cloudflare配下で504が出るときの基本方針
Cloudflare配下で504が出る場合も、基本は「どこで待っているか」を切り分けることです。方針としては次の順で進めると整理しやすいです。
エッジが返しているのか、オリジンが返しているのかを特定する
可能ならオリジン直アクセスで比較し、CDN由来かオリジン由来かを分ける
オリジン由来なら、Nginx→アプリ→DB/外部APIの順で遅延を突合する
タイムアウト延長は最後の手段として、層の整合と同時実行制御も含めて設計する
再発防止は、遅い処理の改善（DB/キャッシュ/非同期化）と前兆監視の導入が王道