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

Cloudflare 520（Web server returned an unknown error）が出たとき、最初の30分でやること

Cloudflare 520（unknown error）を、直近変更/オリジン5xx/レスポンス不正/過負荷で30分切り分ける。

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

Cloudflareで 520 Web server returned an unknown error が出たときは、まず「Cloudflareはエラーを返したが、原因はオリジン側（アプリ/リバプロ/負荷/レスポンス不正）に寄っている」として扱うのが最短です。

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

関連:

  • /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/search-console-server-error-5xx-first-30-minutes

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

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

  1. 520で確定（Cloudflare側のエラー番号・発生URL・発生率）
  2. 影響範囲を固定（全員/一部地域/一部URL/自分だけ）
  3. オリジンのログ/メトリクスを見る（直近デプロイ/5xx/タイムアウト/メモリ/CPU）
  4. 直前変更の切り戻し（アプリ/設定/依存/DB/キャッシュ）
  5. Cloudflare側で追加観測（Ray ID/Events/Firewall/WAF/Transform/Cache）

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

まず「本当に520か」を確定します（似た症状でも原因が違います）。

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

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

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

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

判断の目安:

  • 全員・全ページで520: 直近デプロイ/依存/アプリ停止/過負荷を優先
  • 一部パスだけ520: ルーティング/特定API/バックエンド依存の疑い
  • 自分だけ520: ローカルDNS/キャッシュ/ブラウザ拡張も残す（ただし520自体はサーバー側）

3. オリジン側の“直近変化”を探す（最短で効く）

520は「Cloudflareが原因を特定できない形で失敗した」だけで、オリジンのエラーが埋もれていることが多いです。

最優先で見るもの:

  • 直近デプロイ（数分〜数時間）で 何が変わったか
  • アプリ/リバプロ（Nginx等）のログで 5xx/タイムアウト/例外 が増えていないか
  • CPU/メモリ/コネクション数/DB接続数 が跳ねていないか
  • 外部依存（決済/メール/DB/キュー/ストレージ）が落ちていないか

ここで「直近変更が怪しい」なら、原因が完全に特定できなくても 切り戻し の方が早いです。

4. “レスポンス不正”を疑う（見落としやすい）

520は、オリジンが返すレスポンスが壊れているときにも起きやすいです。

チェックリスト:

  • 直近で ヘッダー/圧縮/転送 周りを変えていないか
  • 途中で接続が切れていないか（途中で0byte/途中切断）
  • 一部のエンドポイントだけ 巨大レスポンス/無限リダイレクト になっていないか

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

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

  • 直前のデプロイをロールバック
  • 直前の設定変更（リバプロ/環境変数/Feature flag）を戻す
  • 直前のDBマイグレーションが疑わしい場合は、アプリ側の参照を旧仕様に戻す
  • 過負荷が疑わしい場合は、スケール/レート制限/キャッシュで止血（根治は後）

6. Cloudflare側で追加観測（Ray IDを使う）

Cloudflareのエラー画面に Ray ID が出ているなら、それを手がかりにログ/イベントを追います。

  • Cloudflareの Events で同時刻に何が起きているか
  • WAF/Firewallで遮断やチャレンジが増えていないか
  • 直前に Transform Rules / Redirect Rules / Cache を触っていないか

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

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

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

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

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

この記事を書いた人

川原

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

著者情報

関連記事

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

次にやること

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

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