CloudflareでRedirect RulesやTransform Rules、WAF、Cache Rulesを設定したのに、WordPressの一部URLだけ期待どおり動かないことがあります。条件式を見直しても原因が分からないときは、Cloudflare Traceで「この要求なら、どの設定がどの順番で評価されるか」を確認できます。
ただし、Traceは実際の訪問履歴を検索する機能ではありません。URL、HTTPメソッド、Cookie、地域などを指定して作るシミュレーションです。実際に起きた障害の証拠は、Security Events、Log Explorer、ブラウザー、オリジンサーバーのログと組み合わせて確認します。
最初に、失敗した完全なURL、時刻、HTTPメソッド、利用者条件、直前の設定変更を保存してください。その情報をTraceへ移し、正常条件と異常条件を一つずつ比較すると、推測で複数設定を止めるより安全に原因を絞れます。
先に結論：Cloudflare Traceは7段階で使う
- 失敗した完全なURL、メソッド、時刻、利用者条件を保存する
- Traceで確認できる設定か、制限事項に該当しないか確認する
- 対象URLとHTTPメソッドを入力する
- 必要なCookie、ヘッダー、地域、Bot Score、Bodyだけを再現する
- 評価された設定、実行された設定、非一致の設定を順番に読む
- 正常条件と異常条件の差を一項目ずつ比較する
- Traceに出ない機能はSecurity Eventsやオリジンログで補う
Traceで一致したから本番でも必ず同じ結果になる、非一致だからそのルールに問題がない、とは限りません。入力条件の不足、Trace非対応の機能、実トラフィックだけで発生する状態が残るためです。Traceは原因候補を狭める道具として使います。
Cloudflare Traceとは？
Cloudflare公式のTrace概要では、TraceはHTTPまたはHTTPS要求がCloudflareの設定でどう処理されるかをシミュレーションするBeta機能と説明されています。2026年8月18日に確認した時点では全プランで利用でき、AdministratorまたはSuper Administratorの権限が必要です。
対象ホストのDNSレコードがCloudflareでプロキシされていない場合でも、「プロキシされていたら適用された設定」を返します。そのため、Trace結果が出たことだけで、本番通信が実際にCloudflareを通っているとは判断できません。DNSのProxy statusは別に確認します。
停止中のルールは評価されません。結果では、Ruleset Engineを使う各製品、Page Rules、Workersなどの評価・実行状況を順番に確認できます。どの製品まで到達し、どこで一致・停止・上書きが起きる可能性があるかを見るのが基本です。
Traceとログ・実アクセスの違い
| 確認方法 | 分かること | 向く場面 | 注意点 |
|---|---|---|---|
| Cloudflare Trace | 指定条件で評価される設定と順序 | ルールが一致しない理由の比較 | 実トラフィック履歴ではない |
| Security Events | WAFなどが実際の要求へ行った判断 | Block・Challenge・Skipの調査 | すべてのRules製品を一括表示する画面ではない |
| Log Explorer・Logpush | 実通信の履歴や傾向 | 発生時刻・複数要求・地域差の調査 | プランや保存範囲を確認する |
| ブラウザー | 最終URL、応答コード、受信ヘッダー | 転送・キャッシュ・表示結果の確認 | Cloudflare内部の全評価順は見えない |
| オリジンログ | サーバーへ届いた要求、パス、ヘッダー | Cloudflare通過後の値を確認 | オリジンへ届く前に止まった要求は残らない |
公式は、Traceを「what-if」の確認、Log Explorerを実際に起きた通信の調査に使い分けています。発生済みのブロックをTraceだけで再現しようとせず、発生時刻とRay IDがある場合は実イベントも探してください。
Traceを作る前に保存する情報
- 失敗した完全なURLと、正常な比較URL
- GET・POST・PUT・PATCHなどのHTTPメソッド
- 発生時刻、タイムゾーン、Ray ID
- ログイン中・未ログイン、管理者・一般利用者の別
- 利用ブラウザー、アプリ、外部サービス
- 必要なUser-Agent、Cookie、要求ヘッダー
- 国・地域・回線による再現差
- 直前に変更したRules、Workers、Snippets、DNS
- 現在のルール名、状態、条件式、順序
- 変更前に正常だった設定やスクリーンショット
CookieやAuthorizationヘッダーには、ログイン情報、セッション、APIキー、個人情報が含まれる場合があります。共有用の記録では値を伏せ、Traceへ入れる場合も再現に必要な最小項目だけにしてください。
ダッシュボードでTraceを作る手順
1. 対象アカウントとドメインを確認する
Cloudflare公式のTrace実行手順を開き、Cloudflareへログインして対象ドメインがあるアカウントを選びます。Traceへ入力するホスト名は、自分のアカウントに属している必要があります。似た検証ドメインや旧ドメインを選ばないよう、zone名を先に確認します。
2. 失敗した完全なURLを入力する
トップページだけではなく、実際に失敗したパスとクエリまで入れます。/wp-login.php、/wp-admin/、/wp-json/、プレビューURL、検索URLは、同じドメインでも一致するルールが変わります。
3. HTTPメソッドとBodyを合わせる
閲覧ならGETが多い一方、ログイン、投稿保存、フォーム、REST APIはPOST・PUT・PATCHなどを使います。公式手順ではPOST・PUT・PATCHを選ぶ場合、Request Bodyも入力できます。内容を再現するときは秘密情報を除き、実データを送信する操作と混同しないでください。
4. 必要な要求条件だけ追加する
- HTTPプロトコル
- User-Agentと要求ヘッダー
- Cookie
- アクセス元の国・地域・都市
- Bot Score
- POST・PUT・PATCHのRequest Body
- Cloudflare Challengeを越えた後まで見るSkip Challenge
最初からすべてを入れず、ルール条件に使っている項目から追加します。例えば国条件なら国、ログイン除外なら該当Cookie、外部連携ならUser-Agentや特定ヘッダーという順です。未指定値を推測で埋めると、実際とは別の要求を検証することになります。
5. Traceを実行して評価順を開く
Send Traceを実行すると、各製品の設定が評価された順に並びます。初期表示で一致・実行された項目を確認し、原因が見つからなければ結果表示をAll configurationsへ切り替え、評価されたが一致しなかった有効設定も確認します。
6. ルール名・条件・結果を保存する
対象製品、ルール名、評価結果、実行順、入力条件を記録します。設定変更後に同じTraceを作れるよう、ダッシュボードに表示されるTrace設定のJSONも保存できます。共有するときはCookieやヘッダー値に秘密情報が残っていないか確認してください。
7. 一項目だけ変えて再実行する
正常・異常を比べるときは、URL、メソッド、Cookie、国、User-Agentなどを一度に変えません。一つだけ変え、どのルールの一致結果が変わったかを確認します。複数項目を同時に変えると、原因の特定ができません。
Traceの入力へ、本番の認証Cookie、Authorization、APIキー、個人情報をそのまま貼り付けて保存・共有しないでください。必要な値だけを安全に扱い、不要になった記録は適切に管理します。
Trace結果の読み方
評価された設定と実行された設定を分ける
ルールが一覧に出たことと、条件に一致してアクションが実行されたことは別です。対象製品まで要求が進んだか、ルールが有効か、条件式が一致したか、アクションが実行されたかを分けて読みます。
非一致の設定をAll configurationsで確認する
期待したルールが実行結果に出ない場合は、All configurationsで非一致の有効ルールまで表示します。ホスト、パス、メソッド、Cookie、国など、どの入力条件が式と違うかを確認します。停止中のルールは評価されないため、状態も設定画面で照合します。
前のフェーズでURLが変わっていないか見る
Single Redirects、URL normalization、URL Rewrite Rulesなど、前の処理でURLやパスが変わると、後のWAF・Origin Rules・Cache Rulesは変更後の値を見る場合があります。元URLだけを見て条件式が正しいと判断せず、評価順の途中で値が変わっていないか確認します。
URL Rewrite Ruleで無効なパスが作られる場合は、Cloudflare Error 1035の確認手順も使い、書き換え後パス、先頭スラッシュ、ルール順を確認してください。
終端アクションで止まっていないか見る
Block、Redirect、Challengeなど、要求をその場で終わらせるアクションが先に一致すると、後のフェーズまで進みません。後ろのルールが「効かない」のではなく、そこへ到達していない可能性があります。
後のルールに上書きされていないか見る
同じフェーズの非終端変更では、後のルールが前の変更を上書きする場合があります。Traceで期待したルールが一致していても、同じヘッダー、キャッシュ設定、接続先などへ後続ルールが別の値を設定していないか最後まで確認します。
Request Header Transform Ruleで変更禁止ヘッダーを触っている場合はError 1040の確認手順、値の形式や長さに問題がある場合はError 1041の確認手順へ進みます。
正常条件と異常条件を比較する
- 正常URLでTraceを作り、入力JSONと結果を保存する
- 異常URLで同じメソッド・ヘッダー条件のTraceを作る
- 最初に結果が分かれたフェーズを探す
- そのフェーズの一致・非一致ルールを比較する
- URL、Cookie、国など一項目だけ正常側へ戻して再実行する
- 一致結果が変わった項目と条件式を照合する
- 設定を直す前に、対象外URLへ影響しない条件を決める
比較では「結果が最後に違う場所」ではなく、「最初に分かれた場所」を探します。後の差は、前のURL書き換えや終端アクションから連鎖している可能性があるためです。
WordPressで確認したい代表URL
| 確認対象 | 代表例 | 見る条件 |
|---|---|---|
| 公開ページ | トップ、投稿、固定ページ | 転送、WAF、Cache、Snippets |
| ログイン | /wp-login.php | POST、Cookie、Rate limiting、Challenge |
| 管理画面 | /wp-admin/ | ログインCookie、Redirect、Cache除外 |
| REST API | /wp-json/ | メソッド、Authorization、WAF、ヘッダー |
| プレビュー | ?preview=trueを含むURL | クエリ、Cookie、Cache除外 |
| フォーム | 送信先URL | POST、Body、WAF、Bot条件 |
| 検索 | ?s=... | クエリ、Cache、Rate limiting |
公開ページで成功しても、ログイン、投稿保存、REST API、フォームが同じとは限りません。ルールを直した後は、閲覧だけでなく更新系URLも検証します。ただし、本番の決済や問い合わせを連打せず、テスト用データと安全な環境を使ってください。
Traceに表示されない機能と限界
Cloudflare公式のTrace制限事項では、結果へ出ない機能や対応しない構成が明記されています。Traceに表示されないことを「設定が存在しない」「本番で動かなかった」と読み替えないでください。
- 運用上の理由で自動的にバイパスされたルールは表示されない場合がある
- Data Localization Suiteを使うホスト名は非対応
- Spectrumアプリケーションは非対応
- 旧Firewall Rulesは結果へ表示されない
- Load BalancingとLoad Balancer Custom Rulesは表示されない
- IP Access rulesは表示されない
- 旧Rate limiting rulesと旧WAF managed rulesは表示されない
- Content security rulesは表示されない
特にIP Access Allowは、後続のWAF評価へ影響する場合がありますが、Traceには表示されません。Trace上でWAFルールが一致するのに実アクセスではイベントが見つからない場合、IP Access rulesや別の除外設定を確認します。
Snippetsの使い分けや適用条件が曖昧なら、Cloudflare SnippetsとRules・Workersの判断ガイドで設計を見直します。Error 1201〜1206が出ている場合は、Snippetsエラーの原因別確認手順へ進んでください。
Traceで原因が分からないときの次の確認先
| 状況 | 次に確認する場所 | 目的 |
|---|---|---|
| Traceでは一致、本番では動かない | DNS Proxy status、実応答ヘッダー、オリジンログ | 実通信が同じ経路か確認 |
| WAFブロックの履歴を見たい | Security Events | 実アクション、ルールID、時刻を確認 |
| IPごとに挙動が違う | IP Access rules、Custom Rules、国・ASN条件 | Trace非表示のAllowや除外を確認 |
| 時間帯・多数要求でだけ失敗 | Log Explorer、Logpush、Rate limiting | 実トラフィックの量と傾向を確認 |
| オリジンへ届いた値を見たい | Webサーバー・アプリログ | 変更後パス・ヘッダー・接続先を確認 |
| ルールの順序や競合が疑わしい | TraceとRules設定一覧 | フェーズ、終端、上書きを確認 |
条件式、フェーズ、上書きの確認方法は、Cloudflare Rulesが効かないときの原因別確認手順で詳しく整理しています。Traceで差が見えた後は、その原因だけを修正してください。
やってはいけないこと
- 失敗URLや時刻を保存せずルールを削除する
- Traceを実トラフィック履歴だと思い込む
- Traceに出ない機能は動いていないと決めつける
- Cookie、Authorization、APIキーをそのまま保存・共有する
- 正常・異常の複数条件を同時に変える
- 本番のログイン・決済・フォームを繰り返し送信する
- WAF、DNS、Cache、Workersを一度に変更する
- 公開ページだけで直ったと判断する
- Trace結果だけでCloudflare全体を停止する
よくある質問
Cloudflare Traceは無料で使えますか？
2026年8月18日に確認した公式資料では全プランで利用できます。ただし、AdministratorまたはSuper Administratorの権限が必要です。提供条件やBetaの仕様は変わる可能性があるため、利用時に公式画面も確認してください。
DNS onlyのホストでもTraceできますか？
公式資料では、プロキシされていないホストでも、Cloudflareを通った場合に適用される設定を返します。ただし、実通信がCloudflareを通っている証明にはなりません。DNSのProxy statusを別に確認してください。
Traceで一致したのに本番でルールが効かないのはなぜですか？
実際の要求がTraceと違う、DNS onlyでCloudflareを通っていない、IP Access rulesなどTrace非表示の機能が影響している、後続ルールに上書きされた、実トラフィックだけの状態がある、といった可能性があります。実イベントとオリジンログを照合してください。
Traceを実行すると本番サイトへ変更が入りますか？
Traceは指定した要求をシミュレーションして設定の評価結果を見る機能です。ただし、Trace結果を見た後に設定を編集・保存すれば本番へ影響します。変更前の設定を保存し、対象条件を狭くして確認してください。
まとめ
Cloudflare Traceは、URL、メソッド、Cookie、地域などを指定し、どの設定がどの順番で評価されるかを見るシミュレーション機能です。実トラフィック履歴ではないため、Security Events、ログ、ブラウザー、オリジンの記録と役割を分けます。
正常条件と異常条件を一つずつ変え、最初に結果が分かれたフェーズを探すことが、原因を短く安全に絞るポイントです。Traceに出ない機能も確認し、原因となる一項目だけを修正してください。