Cloudflareの障害か確認する方法|サイトが開けない・522・524エラーへの対処

WebサイトにCloudflareのエラー画面が出ても、Cloudflare全体の障害とは限りません。配信元サーバーが応答しない時にも表示されます。閲覧者ができる確認と、サイト管理者が調べる内容を分けて説明します。

【要点】エラー番号とRay IDを残す

• URL、時刻、エラー番号、表示されるRay IDを控えます。
• 一つのサイトだけか、複数の無関係なサイトで起きるかを確認します。
• 522・524は配信元との通信・応答も確認します。
• 管理者はWAFやSSL保護を一括停止せず、ログから影響範囲を絞ります。

公式サービス障害モニターほかのサービスの障害・メンテナンス・復旧履歴を確認

Cloudflareの世界各地の製品・拠点に関する公開情報です。掲載された障害がそのまま日本の全サイトへ影響するわけではありません。対象製品・地域・機能を照合してください。

閲覧者と管理者でできることが違う

サイトを見る側の確認手順

1. エラー画面を保存します。個人情報やログイン用URLが写る場合は共有範囲を限定します。
2. 少し待って一度再読み込みします。購入・申請の送信直後なら、先に処理結果を確認します。
3. 別の許可されたブラウザで同じURLを確認します。他のサイトも開けないなら回線側を調べます。
4. 同じサイトだけ繰り返し失敗する場合は運営者へ連絡します。パスワード変更やアプリ再インストールは不要なことがあります。

閲覧者がCloudflareを停止したり、配信元を再起動したりすることはできません。エラー画面を根拠に「自分のPCが故障した」と考えず、まず影響範囲を確認します。会社指定のVPNやセキュリティソフトは無断で止めないでください。

管理者が522・524で確認する点

Cloudflare公式の522の説明では、配信元への接続タイムアウトが扱われています。配信元の稼働、ネットワーク、ファイアウォール、正しい接続先を確認します。Cloudflare側に大規模障害がない時でも、配信元側の問題は起きます。

524の公式説明は、接続後に配信元が時間内に応答しない状況を扱っています。発生URLとアプリの処理時間、DBの重い処理、リソースを照合します。エラーが出てもバックエンド処理が継続している可能性があるため、書き込み処理の再送前に実行結果を確認してください。

設定を変更する前の確認

DNS、WAF、SSL、キャッシュを同時に変更すると原因を追いにくくなります。直前の変更とエラー発生時刻を照合し、設定を保存してから、根拠のある一項目だけを変更します。配信元の直接公開やWAF停止は攻撃への露出を変えるため、安易な切り分けに使いません。

Ray IDと時刻、リクエストURLをログと照合します。サポートへ渡す場合は必要な診断情報に絞り、Cookie、Authorizationヘッダー、個人情報を含むクエリを除いてください。アクセス拒否の調査では、全ユーザーの保護を外すのでなく、該当ルールと対象リクエストを確認します。

閲覧者とサイト管理者で行えることは違う

閲覧者は、失敗したページ、時刻、エラー番号、表示されたRay IDを運営者へ伝えます。ほかのサイトを開けるかの確認はできますが、配信元サーバーの再起動や設定変更はできません。購入・申請の送信直後にエラーになった場合は、先に受付メールや履歴を確認し、未受付と分かるまで連続送信を避けます。

管理者は同じ時刻の配信元ログ、負荷、接続制限と照合します。Cloudflareの公開障害と発生時刻が重なっても、必ずそれだけが原因とは限りません。逆に公開情報が正常でも、自社の一部経路が正常である保証にはなりません。変更する際は現在値と戻し方を記録し、プロキシやWAFの無効化を最初の一手にしないでください。解消の確認は閲覧と書き込みを分けて行います。

まとめ

Cloudflareのエラーでは、公開障害と配信元の問題を分けることが重要です。復旧後はトップページだけでなく、ログイン、フォーム、APIなど必要な機能を確認します。応答が戻っただけで書き込み処理や注文が完了したとせず、業務側の記録も照合してください。

国内の通信・アプリ・企業システム障害のまとめを見る