SiteOps
トップメディアダッシュボード更新履歴
記事一覧

Cloudflare 504 Gateway Timeoutが出たとき、最初の30分でやること

Cloudflare 504（Gateway Timeout）を、Cloudflare→オリジン/オリジン→上流/直前変更で30分切り分ける。

著者: 川原更新: 2026-05-18障害対応RSS
Xで共有FacebookLinkedIn
料金相談

Cloudflareで 504 Gateway Timeout が出たときは、まず「どこでタイムアウトしたのか（Cloudflare→オリジン / オリジン→上流 / アプリ内部）」を30分で切り分けるのが最短です。

この記事は、504が出て「急に遅くなった/一部だけ落ちた」状況になったとき、最初の30分で“止血”するチェックリストです。

関連:

  • /media/cloudflare-502-bad-gateway-first-30-minutes
  • /media/cloudflare-520-web-server-returned-unknown-error-first-30-minutes
  • /media/cloudflare-524-timeout-first-30-minutes
  • /media/search-console-server-error-5xx-first-30-minutes

0. まず結論（先にやる順番）

最初の30分は「直す」より「どこで詰まっているか（境界）を確定」を優先します。

  1. 504で確定（Cloudflareか/オリジンか、発生URL・発生率）
  2. 影響範囲を固定（全員/一部地域/一部URL/自分だけ）
  3. Cloudflare側の“自爆”を除外（WAF/Rules/Workers/キャッシュ）
  4. オリジンの健全性を確認（CPU/メモリ/DB接続/ログ/再起動ループ）
  5. 上流（DB/外部API）起因を疑う（特定パスだけ/特定機能だけ）
  6. 直前変更の切り戻し（デプロイ/設定/環境変数/依存更新）

1. 504で確定する（推理禁止）

まず「本当に504か」「Cloudflareが返している504か」を確定します（初動が変わります）。

  • ブラウザのエラー画面に 504 が出ているか
  • Cloudflareダッシュボードの Events / Analytics で、504が増えているか
  • 可能なら curl -I <URL> を複数回実行し、再現率 を把握する

チェックポイント（最短）:

  • レスポンスヘッダーに server: cloudflare が入るか（入るならCloudflare経由）
  • Cloudflareのエラー画面に Ray ID が出るか（出るならCloudflare側で観測できています）

2. 影響範囲を固定する（最優先）

次を順に試して、影響範囲を固定します。

  • 別端末（スマホ/PC）で同じURLを見る
  • 別回線（モバイル回線）で見る
  • 別リージョン（VPNなどが使えるなら）で見る
  • 別URL（トップだけ/サブページだけ/特定パスだけ）で傾向を見る

判断の目安:

  • 全員・全ページで504: オリジン過負荷/リソース枯渇/上流全落ち/直前デプロイを優先
  • 一部パスだけ504: 特定API/DB/外部サービス起因を優先（「そのパスだけ通る上流」）
  • 自分だけ504: 504自体はサーバー側が多いが、DNS/キャッシュ/拡張も残す（切り分けは継続）

3. Cloudflare側の“直前変更”を確認する（自爆の除外）

504はオリジン起因が多い一方で、Cloudflareの設定変更で“意図せず遅くなる/詰まる”こともあります。

最優先で見るもの:

  • 直近で WAF / Firewall / Rate Limit を触っていないか（誤爆で遅延/再試行）
  • 直近で Redirect Rules / Transform Rules を触っていないか（ループ/ヘッダー破壊で遅延）
  • 直近で Workers / Routes を触っていないか（外部fetchやKV/DBで詰まっていないか）
  • 直近で キャッシュ（Cache Rules/Bypass/HTMLキャッシュ）を触っていないか（キャッシュミス増→オリジン負荷増）

「直前変更と時刻が一致」するなら、原因が完全に特定できなくても 切り戻し の方が早いです。

4. “Cloudflare→オリジン” と “オリジン→上流” を分ける

504は「どこで待たされているか」で初動が変わります。

4-1. Cloudflare→オリジンが遅い（オリジン応答が返らない）

ありがちな原因:

  • オリジンが過負荷（CPU/メモリ/イベントループ飽和）
  • リバプロ（Nginx等）やアプリが 接続を捌けない（接続数/ファイルディスクリプタ枯渇）
  • オリジンが 再起動ループ している（コンテナ/Pod/VM）

4-2. オリジン→上流が遅い（DB/外部APIで詰まる）

ありがちな原因:

  • DB（接続枯渇/ロック/重いクエリ/スロークエリ）
  • 外部API（タイムアウト/レート制限/障害）
  • キュー/ジョブ（詰まり→同期処理が巻き込まれる）

切り分けのコツ:

  • 特定パスだけ504 なら「そのパスが叩く上流」が原因のことが多い
  • 全ページで遅い なら「オリジン全体のリソース枯渇/直前変更」が多い

5. 30分の止血（原因が特定できないとき）

原因特定に時間がかかるときは、復旧優先で止血します。

  • 直前のデプロイをロールバック（最短）
  • 直前の設定変更（Cloudflare Rules/Workers/キャッシュ）を戻す（安全な範囲で）
  • 重い機能の一時停止（検索/集計/外部API連携など）
  • 可能なら タイムアウトを短く して被害を局所化（待ち続けて枯渇するのを防ぐ）

相談する（SiteOps）

状況が複合していて切り分けが進まない場合は、相談だけ先に進めるのも有効です。

  • 料金・導入の概要を見る
  • 相談する

関連

  • /media/cloudflare-524-timeout-first-30-minutes
  • /media/cloudflare-502-bad-gateway-first-30-minutes
  • /media/cloudflare-520-web-server-returned-unknown-error-first-30-minutes

この記事を書いた人

川原

SiteOps編集チームの公開窓口として、検索、アクセス、収益データをもとにした運営判断の知見をまとめています。

著者情報

関連記事

Cloudflare 502 Bad Gatewayが出たとき、最初の30分でやること障害対応更新: 2026-05-18Cloudflare 520（Web server returned an unknown error）が出たとき、最初の30分でやること障害対応更新: 2026-05-18Cloudflare 521（Web server is down）が出たとき、最初の30分でやること障害対応更新: 2026-05-18
前の記事Cloudflare 502 Bad Gatewayが出たとき、最初の30分でやること次の記事Cloudflare 520（Web server returned an unknown error）が出たとき、最初の30分でやること

次にやること

複数サイトの検索、アクセス、収益データをまとめて見直すなら、SiteOpsのダッシュボードでサイト別に確認できます。

料金を見る相談したい / お問い合わせ