Cloudflare 521(Web server is down)が出たとき、最初の30分でやること
Cloudflare 521(Web server is down)を、オリジン停止/到達不可/拒否/DNS取り違えで30分切り分ける。
Cloudflareで 521 Web server is down が出たときは、まず「Cloudflare → オリジン(サーバー)が落ちている/到達できない/拒否されている」のどれかとして扱うのが最短です。
この記事は、521が出て「サイトが落ちた/一部だけ落ちた」状況になったとき、最初の30分で“止血”するチェックリストです。
関連:
- /media/cloudflare-524-timeout-first-30-minutes
- /media/cloudflare-525-ssl-handshake-failed-first-30-minutes
- /media/cloudflare-526-invalid-ssl-certificate-first-30-minutes
- /media/search-console-server-error-5xx-first-30-minutes
0. まず結論(先にやる順番)
最初の30分は「直す」より「壊れている場所を確定する」を優先します。
- 521で確定(Cloudflare側のエラー番号・発生URL・発生率)
- 影響範囲を固定(全員/一部地域/一部URL/自分だけ)
- オリジンが生きているか確認(Cloudflareを経由しない観測ができるなら最優先)
- 拒否されていないか確認(Firewall/セキュリティグループ/allowlist)
- 最短の切り戻し(直前のオリジン/ネットワーク/DNS/Cloudflare設定変更)
1. 521で確定する(推理禁止)
まず「本当に521か」を確定します(似た症状でも原因が違います)。
- ブラウザのエラー画面に 521 が出ているか
- Cloudflareダッシュボードの Events / Analytics で、521が増えているか
- もし可能なら
curl -I <URL>を複数回実行し、再現率 を把握する
2. 影響範囲を固定する(最優先)
次を順に試して、影響範囲を固定します。
- 別端末(スマホ/PC)で同じURLを見る
- 別回線(モバイル回線)で見る
- 別リージョン(VPNなどが使えるなら)で見る
- 別URL(トップだけ/サブページだけ/特定パスだけ)で傾向を見る
判断の目安:
- 全員・全ページで521: オリジン停止/DNS/Firewall/Allowlistを優先
- 一部パスだけ521: オリジンのルーティング(LB/リバプロ/アプリ)や特定ホストの疑い
- 自分だけ521: ローカルDNS/キャッシュ/ブラウザ拡張/ネットワークの可能性も残す
3. まずオリジンが“生きている”かを確認する
521は「オリジンが落ちている」以外にも、「生きているが到達できない/拒否される」でも起きます。
可能なら、Cloudflareを介さずオリジンの状態を観測します。
- オリジン直叩きの ヘルスチェック があるなら、まずそれを見る
- 監視(Uptime/アプリ監視/ホスティング側ステータス)があれば、直近の異常 を確認
- オリジンが複数台なら、片系だけ落ちていないか(ローリング更新/スケール/障害)
ここで「オリジンが落ちている」が濃厚なら、まず復旧(再起動/ロールバック/スケール)に寄せます。
4. “拒否”されていないか(最頻出の見落とし)
オリジンが生きているのに521が出るときは、Firewall/セキュリティグループなどで Cloudflareからのアクセスが拒否 されているケースが多いです。
チェックリスト:
- 直前にFirewall/セキュリティグループ/リバプロ設定を変えていないか
- オリジンが Cloudflare IPレンジ を許可しているか(許可/拒否のルールを確認)
- “Bot対策” “Geoブロック” “Rate limit” で誤爆していないか
- ポート が正しいか(Cloudflareが到達できるポートか/オリジン側がLISTENしているか)
止血の優先順位:
- 一時的に 許可ルールを広げる(復旧優先)→ 収束後に最小化
5. DNSの取り違え(オリジンを指していない)
DNSが別オリジンを指してしまっていると、当然521になります。
- 直前にDNSを触っていないか(A/AAAA/CNAMEの変更、移管、TTL)
- “本番” のつもりが “別環境” を指していないか(stg向けIPなど)
- IPv6(AAAA)が残っており、片方だけ違うオリジンを指していないか
6. “今すぐ復旧”のための切り戻し候補
原因特定に時間がかかるときは、復旧優先の切り戻しを先に検討します(最初の30分の範囲)。
- 直前のオリジン変更(デプロイ/設定/スケール)を戻す
- 直前のFirewall/セキュリティグループ変更を戻す
- 直前のDNS変更を戻す(切り戻しが安全な場合)
- 直前のCloudflare設定変更(Proxy/DNS/ルーティング/WAF)を戻す
※ 恒久対応(監視や変更手順の整備)は、止血後にやります。
7. 再発防止(30分の外)
復旧後に、次のどれかを最低1つ入れると再発率が下がります。
- オリジンの 死活監視(外形監視 + アプリ監視)
- 変更の 記録(いつ・何を変えたかがすぐ追える)
- Cloudflare → オリジンの拒否ログを すぐ見れる場所 に集約
状況が再現しない/原因が複合している場合は、相談だけ先に進めるのも有効です。
この記事を書いた人
川原
SiteOps編集チームの公開窓口として、検索、アクセス、収益データをもとにした運営判断の知見をまとめています。
関連記事
次にやること
複数サイトの検索、アクセス、収益データをまとめて見直すなら、SiteOpsのダッシュボードでサイト別に確認できます。
料金を見る相談したい / お問い合わせ