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

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

Cloudflare 502（Bad Gateway）を、直前変更/Cloudflare側の自爆/オリジン停止/上流依存で30分切り分ける。

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

Cloudflareで 502 Bad Gateway が出たときは、まず「Cloudflareがオリジン（アプリ/リバプロ/上流）から “正しいHTTP応答” を受け取れなかった」として扱うのが最短です。

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

関連:

  • /media/cloudflare-520-web-server-returned-unknown-error-first-30-minutes
  • /media/cloudflare-521-web-server-down-first-30-minutes
  • /media/cloudflare-522-connection-timed-out-first-30-minutes
  • /media/cloudflare-523-origin-is-unreachable-first-30-minutes
  • /media/cloudflare-524-timeout-first-30-minutes
  • /media/cloudflare-deploy-not-reflected-first-30-minutes
  • /media/search-console-server-error-5xx-first-30-minutes

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

最初の30分は「直す」より「切り分けて止血」を優先します。

  1. 502で確定（Cloudflare側のエラー番号・発生URL・発生率）
  2. 影響範囲を固定（全員/一部地域/一部URL/自分だけ）
  3. Cloudflare側の変化を見て“自爆”を除外（WAF/Transform/Redirect/Workers/キャッシュ）
  4. オリジンの健全性を確認（ログ/メトリクス/再起動/上流依存）
  5. 直前変更の切り戻し（デプロイ/設定/依存/環境変数）

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

まず「本当に502か」を確定します（似た症状でも初動が変わります）。

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

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

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

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

判断の目安:

  • 全員・全ページで502: オリジン停止/デプロイ失敗/依存障害を優先
  • 一部パスだけ502: ルーティング/特定API/バックエンド依存（上流）を優先
  • 自分だけ502: “502自体はサーバー側” だが、DNS/プロキシ/拡張も残す（切り分けは継続）

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

502はオリジン側が原因のことが多いですが、Cloudflare側の設定変更で“自爆”していることもあります。

最優先で見るもの:

  • 直近で WAF / Firewall / Rate Limit を触っていないか
  • 直近で Redirect Rules / Transform Rules を触っていないか（無限リダイレクト/ヘッダー破壊）
  • 直近で Workers / Pages Functions / Routes を触っていないか（例外で502扱いになることがあります）
  • 直近で キャッシュ 周り（Cache Rules/Bypass/HTMLキャッシュ）を触っていないか

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

4. オリジン（アプリ/リバプロ/上流）を“落ちている前提”で確認する

502は「オリジンが 落ちた/壊れた/過負荷で応答が崩れた」ときに起きやすいです。

チェックリスト:

  • オリジンが生きているか（プロセス/Pod/VM/コンテナの 再起動ループ がないか）
  • アプリ/リバプロ（Nginx等）のログで 5xx/例外/接続リセット が増えていないか
  • CPU/メモリ/コネクション数/DB接続数 が跳ねていないか
  • 上流依存（DB/外部API/決済/メール/ストレージ）が落ちていないか

5. “一部URLだけ502”のときの最短切り分け

パスやホストで偏るなら、原因はだいたい「そのパスだけ通る上流」です。

  • そのパスが叩く API/DB/外部サービス は何か
  • そのパスだけ リダイレクト/認証/ミドルウェア が入っていないか
  • そのパスだけ 巨大レスポンス になっていないか（上流タイムアウト→応答崩れ）

6. 最短の止血（30分の範囲）

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

  • 直前のデプロイをロールバック
  • 直前の設定変更（Workers/Routes/WAF/Redirect/Transform）を戻す
  • 依存障害が疑わしい場合は、機能を落としてでも「トップと主要導線だけ生かす」（障害の波及を止める）
  • 過負荷が疑わしい場合は、レート制限/キャッシュ/上流のタイムアウト調整で止血（根治は後）

7. 再発防止（30分の外）

復旧後に、次のどれかを最低1つ入れると再発率が下がります。

  • 直近デプロイの「変更点」と「ロールバック手順」を最短で引ける状態にする
  • 502発生時に参照する オリジンログ/メトリクス を固定する
  • 重要な上流依存に タイムアウト/リトライ/フォールバック を入れる

状況が再現しない/原因が複合している場合は、相談だけ先に進めるのも有効です。

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

この記事を書いた人

川原

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

著者情報

関連記事

Cloudflare 504 Gateway Timeoutが出たとき、最初の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 504 Gateway Timeoutが出たとき、最初の30分でやること

次にやること

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

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