Cloudflareで障害が起きているか確認する方法｜WordPressだけの問題と切り分ける手順

WordPressが突然開かない、管理画面が遅い、Cloudflareのエラーが出る。このとき最初にDNS、WAF、キャッシュを次々と変更すると、Cloudflare全体の障害が原因だった場合でも、自分で別の不具合を増やしかねません。

まずCloudflare Statusページで、同じ時刻・サービス・地域に障害やメンテナンスがないかを確認します。そのうえで、自分のWordPressだけか、特定地域だけか、Cloudflareの広い範囲かを証拠で切り分けます。

Statusページに障害があるだけで自サイトの原因と決めず、緑色だからCloudflareは無関係とも決めないでください。公式情報と自サイトの発生時刻、影響サービス、地域、エラーを重ねて判断します。

先に結論｜時刻・サービス・地域・症状を照合する

Cloudflare障害を確認するときは、Statusページの色だけでなく、次の順番で見ます。

自サイトで異常が始まった正確な時刻を保存する
StatusページのActive incidentsを確認する
影響を受けるサービスと地域を読む
インシデントの開始・更新・解消時刻を並べる
別回線や別地域でも同じ症状か確認する
完全URL、HTTP状態、Ray ID、スクリーンショットを保存する
一致しなければCloudflare設定、origin、WordPressへ調査を移す

2026年8月21日時点のCloudflare公式Status案内でも、予期しない挙動があればStatusページの確認が推奨されています。Statusページの通知基盤はCloudflare本体のインフラとは独立しており、Cloudflare側に障害があるときも状態更新を届けられる設計です。

4つの範囲を最初に分ける

問題の範囲	見え方の例	主な確認先	初動
Cloudflare全体・製品障害	複数地域・複数サイトで同時発生	StatusのIncidentとServices	証拠保存、公式更新待ち、不要な変更を止める
地域・経路の問題	特定の国、回線、PoP周辺で発生	StatusのLocations、別回線テスト	地域差を記録し再確認
自分のCloudflare設定	一つのzone、URL、操作だけで発生	Security Events、Rules、通信ログ	変更前に該当証拠を保存
origin・WordPress	サーバー負荷、PHP、DB、プラグインで発生	サーバー状態、WordPress・originログ	Cloudflareを無関係と断定せずorigin側を調査

Cloudflareのダッシュボードだけが開きにくく、公開中のWordPressは正常な場合もあります。反対に、Statusページに一致する障害がなくても、一つのzoneに限った設定ミスや、特定データセンターからoriginへの経路問題は残ります。「CloudflareかWordPressか」の二択にせず、範囲を四つに分けると判断しやすくなります。

調査前に8つの証拠を保存する

異常が始まった日時とJST・UTCなどのタイムゾーン
最後に正常だった日時
影響する完全なURLと操作内容
HTTP状態、Cloudflareエラー番号、ブラウザー表示
Cloudflare Ray IDの確認方法に沿って保存したRay ID
Wi-Fi、携帯回線、別地域での再現差
トップ、記事、管理画面、ログイン、フォームの影響差
直前のデプロイ、更新、DNS・WAF・Rules変更

「昼ごろから重い」ではなく、秒まで分かる時刻を一つ残します。同じエラー画面でも再読み込みでRay IDが変わるため、スクリーンショットと完全URLをセットで保存します。

調査資料へCookie、Authorizationヘッダー、管理画面URLの秘密値を貼り付けないでください。社外へ共有するときは、個人情報、IPアドレス、問い合わせ内容も必要な範囲だけ残します。

Cloudflare Statusページを開く

Cloudflare Statusページを開く
Active incidentsがあるか確認する
該当するインシデントの詳細を開く
影響度、対象サービス、更新履歴を読む
「Services」で製品別の状態を確認する
「Locations」で地域・データセンターの状態を確認する
自サイトの異常時刻と同じ時間帯か照合する

Statusページは現在状態が変化するため、この記事に書かれた特定日の色ではなく、調査時点の画面を確認してください。障害対応中は詳細ページのURLと更新時刻を保存し、数分後の更新と比較します。

Statusページを7項目で読む

項目	確認内容	自サイトとの照合
Status	調査中、特定済み、監視中、解消など	まだ変化する段階か
Impact	minor、major、criticalなど	影響の大きさだけで自サイト原因を断定しない
Components	CDN、DNS、Dashboard、APIなど	異常が出る機能と一致するか
Locations	影響地域やデータセンター	閲覧者の地域・回線と一致するか
Started	開始または検知時刻	自サイトの異常開始と重なるか
Updates	調査内容と状態変化	症状の変化と並行するか
Resolved	解消時刻	解消後に自サイトも戻ったか

表示時刻のタイムゾーンに注意します。自分の記録がJST、StatusページやサーバーログがUTCなら、同じ基準へ直してから比較します。開始時刻が完全一致しなくても、検知まで時間差がある場合を考え、前後の更新を読みます。

WordPressに関係しやすいコンポーネント

コンポーネント	起こり得る見え方	追加確認
CDN / Cache	表示失敗、古い内容、地域差	キャッシュ状態、edge応答、別地域
Authoritative DNS	名前解決失敗、断続的接続	複数resolver、対象レコード
SSL / TLS	証明書警告、HTTPS接続失敗	証明書、暗号化モード、origin HTTPS
WAF / Security	403、Challenge、API失敗	Security Eventsと該当要求
Dashboard / API	設定画面やAPIだけ操作できない	公開サイトが正常か分ける
Network / Locations	特定地域・回線で遅延や到達失敗	Locationsと別回線・別地域

コンポーネント名が似ていても、公開サイトへの影響は同じではありません。Dashboardの障害中に設定変更を繰り返す必要はなく、公開サイトが正常なら運用作業を延期する判断もできます。一方、DNSやCDNの広域障害では、WordPress本体を再起動しても改善しない可能性があります。

Locationsの3状態を読む

Operational：通常運用中
Re-routed：計画・非計画の保守などでデータセンターが経路から外され、別拠点へ迂回
Partially Re-routed：一部のトラフィックを別拠点へ迂回

Re-routedは、その地域の閲覧が必ず失敗するという意味ではありません。通常は別拠点へ経路が変わります。ただし、遅延や経路差が疑われるときは、閲覧者の地域、接続回線、時刻と重ねます。PoP名だけでなく、実際に取得したRay IDや応答ヘッダーのデータセンターコードも保存します。

証拠の組み合わせで影響範囲を判断する

Statusページ	自サイトの証拠	可能性	次の行動
同じ時刻・サービスにIncident	複数地域・複数サイトで同症状	Cloudflareの広域・製品障害が高い	変更を止め、公式更新と復旧後を確認
該当地域がRe-routed	特定地域や回線だけ遅い	地域経路の影響が高い	地域差と時間変化を記録
DashboardだけIncident	公開サイトは正常	管理操作側の障害	公開側を触らず作業を延期
一致するIncidentなし	一つのzone・URLだけ異常	設定、origin、WordPressの可能性	イベント・通信・サーバーログへ進む
IncidentはResolved	自サイトだけ異常が継続	残存キャッシュや別原因	解消後の新しい要求で再調査

これは原因の確定表ではなく、調査の優先順位を決める表です。Statusページと時刻が一致しても、直前のWordPress更新や設定変更が同時に起きていれば両方を残します。逆に、Statusに記載がなくても未検知・限定的な問題の可能性はあるため、「Cloudflareではない」と言い切りません。

Incidentが一致するときの安全な対応

Status詳細URL、現在状態、更新時刻を保存する
自サイトのURL、時刻、HTTP状態、Ray IDを保存する
利用者へ確認中であることと次回更新時刻を案内する
障害と無関係なデプロイ、DNS、WAF、キャッシュ変更を止める
公式更新を一定間隔で確認する
Resolved後に新しいブラウザー・別回線で再確認する
WordPressの主要操作とフォームを確認する
異常が残る場合は自サイト固有の調査へ切り替える

切り分け前にCloudflareのプロキシ停止、nameserver変更、DNSレコードの大量変更を行わないでください。DNS反映待ち、証明書、接続元IP、キャッシュなど別の変数が増え、障害が解消した後も自サイトだけ復旧しない状態を作ることがあります。

一致する障害がないときの確認順

Cloudflareダッシュボードへ入れるか確認する
対象zoneとDNSレコード、Proxied状態を確認する
Cloudflare Security Eventsの見方でWAF・Challenge・Rate limitingを確認する
Cloudflare Log Explorerの使い方で実通信のedge・origin応答を照合する
originサーバーの死活、CPU、メモリ、接続数、Webサーバーログを確認する
WordPressのPHPエラー、DB、プラグイン、テーマ、更新履歴を確認する
直前変更を一項目ずつ検証する

Cloudflareの5xxは番号で確認先が変わります。たとえばCloudflare Error 520の直し方はoriginからの空・不正な応答、Cloudflare Error 524の直し方は接続後の応答待ちを中心に確認します。エラー番号を「Cloudflare障害」という一語にまとめないでください。

Status更新を自動で受け取る

Statusページの「Subscribe to Updates」では、Email、Webhook、Slack、Discord、Google Chatで更新を受け取れます。これはCloudflareアカウント内の通知ポリシーとは別です。自分のaccount・zoneに関係する通知はCloudflare Notificationsの設定方法で用意し、広域のStatus更新と役割を分けます。

フィードで収集する場合は、公式案内にIncidentsとMaintenanceのRSS・Atom URLがあります。自動処理では取得失敗、重複、更新順のずれを考え、状態変更をそのままDNSやサーバー操作へ連動させず、まず記録と担当者への通知に使います。

よくある失敗

Statusページの最上部の色だけを見る
影響サービスや地域を読まず、自サイト原因と断定する
JSTとUTCを混同して無関係なIncidentを結びつける
開始時刻だけを見て更新・解消履歴を確認しない
Dashboard障害と公開サイト障害を混同する
一つのWi-Fiからしか再現確認しない
エラー画面、完全URL、Ray IDを保存せず再読み込みする
Statusが緑という理由だけでCloudflare設定を除外する
広域障害中にDNSやWAFを何度も変更する
Resolved後にログインやフォームを確認しない

確認チェックリスト

異常開始時刻とタイムゾーンを保存した
Active incidentsの詳細を開いた
Impact、Components、Locationsを読んだ
開始・更新・解消時刻を自サイトと照合した
別回線または別地域で再現確認した
完全URL、HTTP状態、Ray IDを保存した
公開サイトとDashboardの影響を分けた
変更前に現在設定と証拠を保存した
Resolved後に新しい要求で再確認した
異常が残る場合はorigin・WordPress調査へ移った

よくある質問

StatusページがOperationalならCloudflareは正常ですか？

全体として報告中の障害がない有力な材料ですが、自分のzoneだけの設定、限定された地域・経路、未検知の問題までは否定できません。Ray ID、別回線、Security Events、originログと合わせて判断します。

Re-routedならサイトは停止しますか？

必ず停止する意味ではありません。対象データセンターを経路から外し、別拠点へ迂回している状態です。実際の遅延・到達状況を地域と回線を変えて確認します。

障害中にCloudflareを一時停止すべきですか？

最初の対応にはしません。影響範囲とoriginの安全な到達方法を確認せずに外すと、IP露出、証明書、DNS、キャッシュなど新しい問題が増えます。公式情報と証拠を保存し、必要性を限定して判断します。

まとめ

Cloudflare障害はStatusページの色だけでなく、時刻・サービス・地域・症状で照合する
Cloudflare全体、地域経路、自分のCloudflare設定、origin・WordPressの4範囲に分ける
Incidentの開始・更新・解消を並べ、別回線とRay IDで影響範囲を確かめる
Statusに一致しても原因確定ではなく、Statusが緑でもCloudflareを完全除外しない
広域障害中は不要なDNS・WAF・キャッシュ変更を止める
Resolved後も異常が残れば、設定・origin・WordPressへ調査を切り替える

障害時に大切なのは、早く設定を変えることではなく、問題の範囲を狭めることです。Statusページと自サイトの証拠を同じ時間軸へ並べれば、待つべき障害と、自分で調べるべき問題を落ち着いて分けられます。