WordPressでCloudflareのエラーページ、403、429、520、522、524などが出たとき、画面下部にRay IDが表示されることがあります。Ray IDを保存しておくと、利用者が失敗した要求をCloudflare Security Eventsやサーバーログの記録と照合しやすくなります。
ただし、Ray IDはエラー原因を直接示すコードではありません。Ray IDだけを送られても、どのURLで何時にどの操作が失敗したか分からなければ、対象要求を特定できない場合があります。完全なURL、正確な時刻、HTTPメソッド、応答コードと一組で保存します。
エラー画面を閉じたり再読み込みしたりする前に、Ray ID、発生時刻とタイムゾーン、完全なURL、表示されたエラー番号を記録してください。POST、決済、フォーム送信、記事保存では、結果を確認せず再実行すると重複処理になる可能性があります。
先に結論：Ray IDは7段階で使う
- 失敗した完全なURL、操作、応答コードを保存する
- エラーページまたは応答ヘッダーからRay IDを確認する
- 秒まで分かる発生時刻とタイムゾーンを記録する
- GET・POSTなどのHTTPメソッドと利用者条件を保存する
- Security Eventsで時刻、Ray ID、IP、Pathを照合する
- 見つからなければオリジンログ、Log Explorer、関連設定を確認する
- 原因となるルールやサーバー処理だけを修正し、同条件で再確認する
Ray IDがあるからCloudflareのWAFが原因とは限りません。Cloudflareを通った要求にはRay IDが付き、オリジン側のPHP・Webサーバー・データベース処理で失敗した場合にも応答ヘッダーで確認できることがあります。エラー番号とログを組み合わせて原因の層を分けます。
Ray IDとは何か
Cloudflare公式のRay ID資料では、Ray IDはCloudflareを通る要求に付与される識別子と説明されています。Security Eventsで誤検知や傾向を調べたり、アプリケーション通信を理解したりするときの手掛かりになります。
Ray IDはエラーメッセージの番号、WAFルールID、WordPress投稿IDとは別物です。Ray IDの文字列だけを見ても、Blockしたルール、利用者の操作、オリジンエラーの原因は分かりません。Cloudflare側とオリジン側に残る同じ要求を結び付けるために使います。
公式資料には、Ray IDがすべての要求で一意になるとは保証されないという注意もあります。そのため、Ray IDだけに依存せず、時刻、URL、メソッド、IP、User-Agentを合わせます。同じRay IDに見える記録が複数ある場合も、他の条件で対象を確認してください。
Ray IDは「原因を答える番号」ではなく、「同じ要求の記録を探すための手掛かり」です。Ray IDがあることだけを根拠に、Cloudflareの障害、WAFの誤ブロック、特定利用者の攻撃と断定しないでください。
Ray IDを確認する3つの方法
1. Cloudflareのエラーページで確認する
Cloudflareが生成したエラーページでは、画面下部にRay IDが表示される場合があります。利用者から報告を受けるときは、Ray IDだけでなく、エラー番号、表示時刻、完全なURLが分かる画面を保存してもらいます。画面全体に個人情報や管理URLが含まれる場合は、共有範囲を限定してください。
再読み込みすると別の要求になり、別のRay IDが付く場合があります。最初に失敗した画面を閉じる前に保存することが重要です。フォームや決済では、再読み込みや戻る操作の前に処理結果も確認します。
2. ブラウザーの応答ヘッダーで確認する
- ブラウザーの開発者ツールを開く
- Networkタブで記録を開始する
- 対象URLを一度だけ読み込む
- 失敗したDocument、Fetch、XHRなどの要求を選ぶ
- Response Headersの
cf-rayを確認する - Status、Request URL、Request Method、時刻も保存する
記事保存やREST APIの失敗では、ページ本体ではなく/wp-json/へのFetch・XHR要求にRay IDが付いている場合があります。問い合わせフォームでは送信先のPOST要求、管理画面の非同期処理では/wp-admin/admin-ajax.phpを確認します。
3. curlの応答ヘッダーで確認する
公開URLのGET確認なら、端末からヘッダーを表示してcf-rayを探せます。次は応答ヘッダーだけを確認する基本例です。
curl -I https://example.com/確認したいパス/リダイレクトを追う場合は-L、詳細な接続情報を確認する場合は-vを使えます。ただし、ログインCookie、Authorization、APIキー、フォーム本文をコマンド履歴や共有資料へ残さないでください。POSTを再現する前に、重複送信の危険がないテスト環境か確認します。
Ray IDと一緒に保存する情報
| 情報 | 必要な理由 | 保存例 |
|---|---|---|
| 完全なURL | Host、Path、Queryを特定する | アドレスバーまたはRequest URL |
| 発生時刻 | ログの時間範囲を狭める | 秒まで、JST・UTCを明記 |
| Ray ID | Cloudflare側とオリジン側を照合する | エラーページまたはcf-ray |
| HTTPメソッド | 閲覧と送信・保存を区別する | GET、POST、PUT |
| 応答コード | 拒否・制限・上流障害を分ける | 403、429、520、522、524 |
| 利用者条件 | 再現差を確認する | ログイン状態、権限、回線、国 |
| IP・User-Agent | 同時刻の似た要求を区別する | 発生時の値 |
| 直前の変更 | 設定差と時系列を確認する | WAF、Rules、プラグイン、更新 |
時刻は「さっき」「午前中」ではなく、できるだけ秒まで保存します。Cloudflare画面、WordPress、Webサーバーでタイムゾーンが違う場合があるため、JST、UTCなども添えます。ログ上の時刻を変換するときは、サマータイムの有無にも注意してください。
Ray IDの末尾には、例として-SJCのような3文字が付く場合があります。Cloudflare公式のCf-Rayヘッダー資料では、応答ヘッダーの末尾3文字は要求を処理したデータセンターを示します。ただし、Argo Smart RoutingやTiered Cachingでは、オリジンへ届くヘッダーが接続側データセンターを示す場合があります。末尾だけを障害原因やオリジン所在地と決めつけないでください。
Ray IDをSecurity Eventsとログで照合する
1. Security Eventsでセキュリティ判断を確認する
対象zoneのAnalyticsからEventsを開き、発生時刻の前後へ期間を狭めます。Ray ID、IP、Host、Pathを使ってSampled logsを絞り、Action、Service、ルール名、ルールIDを確認します。詳しい画面の読み方は、Cloudflare Security Eventsで誤ブロックしたルールを特定する手順で整理しています。
Security Eventsはサンプリングされる場合があり、Ray ID検索で必ずイベントが見つかるとは限りません。時間範囲を狭め、IP、Path、Actionでも照合します。見つからないことだけを根拠にWAFと無関係だと断定しないでください。
2. オリジンサーバーログで到達を確認する
要求がCloudflareを通過してオリジンへ届いた場合、WebサーバーログにCF-Rayを記録する設定があれば、同じ要求を照合できます。公式のトラブルシューティング資料にはApacheとNginxのログ形式へCF-Rayを追加する例があります。設定変更はホスティング会社またはサーバー管理者と行い、変更前の設定を保存してください。
オリジンログに同じRay IDがあれば、少なくともその要求はCloudflareで完全に止まらずサーバーへ届いた可能性があります。PHPエラーログ、アクセスログ、WordPressデバッグログを同じ時刻で確認します。記録がない場合も、ログ設定や保持期間、キャッシュ応答を確認してから到達しなかったと判断します。
3. Log Explorer・Cloudflare Logsで調べる
利用できる契約では、Log ExplorerでRay IDを条件に実トラフィックの記録を検索できます。EnterpriseのCloudflare LogsではRay IDフィールドを有効にできます。Security EventsのSampled logsで見つからない場合でも、利用可能な生ログがあれば、エッジ応答、オリジン応答、キャッシュ状態などを同じ要求で確認できます。
4. Traceで同じ条件を再現する
実イベントの証拠を保存した後、URL、メソッド、Cookie、地域などをCloudflare Traceへ移すと、同条件でどの設定が評価されるか確認できます。Traceは実通信履歴ではないため、Ray IDそのものをTrace結果の証拠として扱わず、実イベントと仮想評価を比較します。
エラー別にRay IDの次を見る場所
| 現象・エラー | Ray IDの次に見る場所 | 主な目的 |
|---|---|---|
| 1020・403 | Security Events、WAF、IP Access | 拒否したルールとActionを特定 |
| 1015・429 | Rate limiting、Retry-After、Security Events | 対象ルール、数え方、期間を確認 |
| 520 | オリジン応答、PHP・Webサーバーログ | 空・不正・早期切断の応答を確認 |
| 522 | 接続待ち、Cloudflare IP制限、サーバー負荷 | オリジンへ接続できない原因を確認 |
| 524 | 長時間処理、PHP、DB、外部API | 接続後に応答が戻らない処理を確認 |
| 保存・REST失敗 | Network、WAF、/wp-json/、PHPログ | 失敗した個別API要求を確認 |
Cloudflare Error 1020ならAccess Denied・WAFの確認順へ進みます。5xxでは、520の不正応答、522の接続タイムアウト、524の応答待ちタイムアウトを分け、同じRay IDの周辺ログを確認してください。
WordPressで保存したい代表的な要求
| 操作 | 確認する要求 | 追加で保存する情報 |
|---|---|---|
| 公開ページ閲覧 | DocumentのGET | 最終URL、キャッシュ状態 |
| ログイン | /wp-login.phpのPOST | ログイン前後、Challengeの有無 |
| 記事保存 | /wp-json/へのPOST・PUT | 保存対象、応答本文、重複可否 |
| 管理画面の非同期処理 | /wp-admin/admin-ajax.php | 実行機能、プラグイン名 |
| 問い合わせ | フォーム送信先のPOST | 送信時刻、送信結果、個人情報除去 |
| Webhook・外部連携 | 固定Pathへの要求 | 送信元IP、User-Agent、再試行回数 |
ページ上にエラーが出た時刻と、実際に失敗したFetch・XHRの時刻がずれる場合があります。開発者ツールではStatusが失敗した要求を選び、その要求のRay IDを保存します。ページ本体のRay IDを、保存APIやフォーム送信のRay IDとして扱わないでください。
POSTやPUTの本文には記事内容、メールアドレス、氏名、認証情報が含まれる場合があります。調査に必要なのがURL、時刻、ヘッダー、応答コードだけなら、Request Payloadを共有しません。HARを渡す場合は次の注意を必ず守ります。
サポートや管理者へ渡す情報
- 問題が起きた完全なURL
- 発生日時、秒、タイムゾーン
- Ray IDまたは
cf-rayヘッダー - HTTPメソッドと応答コード
- エラー画面または必要箇所のスクリーンショット
- 利用ブラウザー、OS、回線、発生時IP
- ログイン状態、利用者権限、再現条件
- 直前に変更したCloudflare・WordPress・サーバー設定
- Security EventsのAction、Service、ルール名・ID
- オリジンアクセスログ、PHPログの同時刻部分
- 必要に応じて機密情報を除去したHAR
- すでに試したことと、その前後の結果
Cloudflare公式のトラブル情報収集ガイドでも、問題調査時にCF-RAYを提供するよう案内されています。一方、HARにはパスワード、決済情報、秘密鍵などが含まれる可能性があります。共有前に内容を確認し、必要なら専用のサニタイズ手段を使います。
Cookie、Authorization、APIキー、パスワード、決済情報、フォーム本文を、スクリーンショット・HAR・curl履歴・チャットへそのまま残さないでください。原因調査に必要なURL、時刻、Ray ID、状態だけを優先し、秘密情報は削除または安全に置き換えます。
Ray IDが見つからないとき
- エラーページがCloudflare生成か、WordPress・サーバー生成か確認する
- 対象要求がCloudflareのProxied DNSを通っているか確認する
- ページ本体ではなく失敗したFetch・XHRの応答ヘッダーを見る
- ブラウザーキャッシュやService Workerの応答ではないか確認する
- 時刻、タイムゾーン、Host、Path、IPを見直す
- Security Eventsの期間を短くしてサンプリングの影響を減らす
- オリジンログにCF-Ray記録設定があるか確認する
- 利用可能ならLog ExplorerまたはCloudflare Logsを確認する
- Ray IDがなくてもURL、時刻、メソッド、応答コードから調査を続ける
Ray IDがないことは、エラーが存在しなかった証明でも、Cloudflareと無関係な証明でもありません。DNS onlyのホスト、ブラウザー内部の失敗、Cloudflareへ到達する前のDNS・TLS障害、オリジンやアプリが独自に返した画面など、どの地点まで通信が進んだかを別の証拠で確認します。
やってはいけないこと
- Ray IDだけを保存してURLと時刻を残さない
- 再読み込み後のRay IDを最初の失敗要求として扱う
- ページ本体とFetch・XHRのRay IDを混同する
- Ray IDをエラー原因やWAFルールIDだと思い込む
- Ray IDは必ず要求ごとに一意だと断定する
- 末尾3文字だけで障害拠点を決めつける
- Security Eventsで0件ならCloudflareと無関係と判断する
- 本番のPOST、決済、保存、フォームを繰り返す
- 認証CookieやHARを無加工で共有する
- 証拠を保存せずWAF・DNS・プラグインを一度に変更する
よくある質問
Ray IDがあればエラー原因が分かりますか？
Ray IDだけでは分かりません。同じ要求のSecurity Events、Cloudflareログ、オリジンログを探す手掛かりです。完全URL、時刻、メソッド、応答コード、利用者条件と組み合わせて原因の層を判断します。
Ray IDは個人情報ですか？
Ray ID単独で訪問者の氏名やパスワードが分かるものではありません。ただし、管理画面ではIP、User-Agent、URLなど関連情報と照合できます。公開掲示板へ不用意に貼らず、調査に必要な管理者・事業者へ限定して共有してください。
同じ画面で複数のRay IDが見つかりました。どれを使いますか？
失敗した要求のRay IDを使います。記事保存なら/wp-json/への失敗したFetch・XHR、フォームなら送信先POST、ページ表示ならDocumentを選びます。Status、URL、Method、時刻が現象と一致するか確認してください。
利用者に何を送ってもらえばよいですか？
完全なURL、発生時刻とタイムゾーン、エラー番号、Ray ID、操作内容、利用ブラウザーを依頼します。スクリーンショットは個人情報を確認してから共有してもらい、パスワードやフォーム本文は送らないよう案内します。
まとめ
Cloudflare Ray IDは、Cloudflareを通った要求の記録をSecurity Events、Log Explorer、オリジンログなどで照合するための識別情報です。エラーページ、ブラウザーの応答ヘッダー、curlから確認できます。
Ray IDは原因そのものではなく、単独で一意とも保証されません。完全URL、秒までの時刻、タイムゾーン、HTTPメソッド、応答コードと一組で保存してください。秘密情報を除去し、同じ要求のCloudflare側とオリジン側の記録を照合すれば、無関係な設定を変えずに原因へ近づけます。