CloudflareでRedirect Rules、Transform Rules、Origin Rules、WAF、Cache Rules、Snippetsなどを設定しても、WordPressの対象ページで期待どおり動かないことがあります。条件式が正しく見えても、DNSがCloudflareを通っていない、前の処理でURLが変わった、別ルールに上書きされた、という原因が残ります。
「ルールが効かない」を直すときは、設定を増やす前に、要求がCloudflareへ届いたか、条件に一致したか、目的のフェーズまで進んだか、後で上書きされたかを分けてください。複数設定を一度に止めると、一時的に直っても原因が分からなくなります。
失敗した完全なURL、HTTPメソッド、時刻、利用者条件、現在のルール一覧を保存してから変更します。Cloudflare Traceと実際のイベント・ログを使い、最初に結果が分かれた場所を一つだけ修正してください。
先に結論：Rulesが効かないときは8段階で確認する
- 失敗URL、メソッド、時刻、直前の変更を保存する
- 対象ホストのDNSレコードとProxy statusを確認する
- ルールが有効で、正しいアカウント・zoneにあるか確認する
- 実際のホスト、パス、クエリ、Cookie、ヘッダーを条件式と照合する
- 前のフェーズでURLや要求値が変わっていないか確認する
- 終端アクション、Skip・Allow、後続ルールの上書きを確認する
- Cloudflare Traceと実イベント・オリジンログで比較する
- 原因となる一項目だけ直し、WordPressの代表URLを再確認する
最初にCloudflare全体を一時停止したり、WAF・Cache・DNSをまとめて変更したりしないでください。原因範囲が広がり、管理画面、ログイン、REST API、フォーム、検索エンジン向けURLへ新しい影響を出す可能性があります。
Cloudflare Rulesが効かない5つの型
| 型 | 状態 | 最初に見る場所 |
|---|---|---|
| Cloudflareへ届かない | DNS only、別ホスト、別zoneを通っている | DNSレコード、Proxy status、要求ホスト |
| 条件に一致しない | パス、メソッド、Cookie、国などが式と違う | 完全な要求値、条件式、Trace |
| 先に処理が終わる | Redirect、Block、Challengeなどで後へ進まない | フェーズ順、終端アクション |
| 後で結果が変わる | 別ルールが上書き、変更後URLを後続機能が評価 | 後続ルール、書き換え後の値 |
| 確認画面に見えない | Trace非対応機能、旧機能、自動バイパスが影響 | Trace制限、Security Events、各設定画面 |
この5つを分けず、「キャッシュのせい」「WAFのせい」と決めつけると、無関係な設定を触りやすくなります。まず現象を分類し、その型に必要な証拠だけを集めます。
変更前に保存する証拠
- 失敗する完全なURLと正常な比較URL
- GET・POSTなどのHTTPメソッド
- 発生時刻、タイムゾーン、Ray ID
- 応答コード、最終URL、応答ヘッダー
- ログイン中・未ログイン、利用者権限の別
- ブラウザー、アプリ、外部サービスなど要求元
- 現在のDNSレコードとProxy status
- 関連ルールの製品名、ルール名、状態、順序
- 条件式と、Set・Rewrite・Block・Skipなどのアクション
- 直前に変更したRules、Workers、Snippets、WordPress設定
- 変更前に正常だった設定と確認結果
認証Cookie、Authorization、APIキー、個人情報を記録へ残す場合は、共有用資料で必ず伏せます。設定を戻せるよう、ルール名だけでなく条件式とアクションの内容も保存してください。
DNSレコードとProxy statusを確認する
Cloudflare公式のRulesトラブルシューティングでは、最初に対象DNSレコードがProxiedか確認するよう案内されています。DNSレコードがDNS onlyなら、訪問者の通信はCloudflareのHTTP処理を通らず、WAFやTransform Rulesなどが適用されません。
- 要求URLのホスト名とDNSレコード名が一致しているか
- A・AAAA・CNAMEレコードが存在するか
- Proxy statusが意図どおりProxiedか
wwwあり・なし、別サブドメインを混同していないか- 対象zoneではなく別アカウントのzoneを編集していないか
- 外部CDN、SaaS、ロードバランサーへ別経路で送っていないか
Cloudflare Traceは、プロキシされていないホストでも「通った場合の設定」を返すことがあります。そのため、Trace結果が表示されたことだけで本番経路を確認せず、DNS画面と実際の応答ヘッダーを照合します。
ルールの状態と配置先を確認する
- ルールがEnabledになっているか
- 正しいアカウント・zone・ホスト向けか
- 同名の旧ルールと新ルールを取り違えていないか
- 保存後にエラーや未反映状態が残っていないか
- 想定するRules製品へ作成したか
- アカウントレベルとzoneレベルの両方に関連ルールがないか
CloudflareのRuleset Engineでは、同じフェーズでアカウントレベルのルールがzoneレベルより先に評価されます。アカウントレベル機能はプラン条件もあるため、見えているzoneルールだけで全設定と判断しないでください。
条件式と実際の要求値を照合する
ホスト名・パス・クエリを完全なURLで見る
example.comとwww.example.com、/wp-adminと/wp-admin/、公開URLとプレビューURLは別条件です。大文字・小文字、末尾スラッシュ、URLエンコード、クエリの有無も確認します。
HTTPメソッドを確認する
GETだけを対象にしたルールは、WordPressログイン、投稿保存、フォーム、REST APIのPOST・PUT・PATCHへ一致しません。画面URLが同じでも、操作によってメソッドが変わる点を確認します。
Cookie・ヘッダー・国条件を確認する
ログインCookieは未ログイン利用者にはありません。外部サービスのUser-Agentや独自ヘッダーも、ブラウザーと同じとは限りません。国条件は利用者の申告住所ではなく、Cloudflareが接続元IPから判定した値を使います。
and・orの優先順位を括弧で明確にする
Cloudflare公式の演算子資料では、論理演算子はnot、and、xor、orの順で優先されます。複合条件は、意図するまとまりを括弧で明示し、Expression Editorで確認します。
条件式を短くするために意味を曖昧にせず、ホスト、パス、メソッド、除外条件を読み直せる形にします。trueは現在のフェーズ・レベルの全要求へ適用する意味になるため、検証用に安易に使わないでください。
Cloudflare Rulesの実行順を確認する
Cloudflareの設定は、画面に並んだ全ルールを一つの上から下へ処理するのではありません。製品ごとにRuleset Engineのフェーズがあり、要求は決められた順番で進みます。
| 主な順序 | 製品・処理 | 後続へ与える影響 |
|---|---|---|
| 早い | Single Redirects | 一致すれば転送して後へ進まない場合がある |
| ↓ | URL normalization | URL表現を正規化する |
| ↓ | URL Rewrite Rules | 後続フェーズが変更後パスを見る場合がある |
| ↓ | Configuration Rules | 機能設定を要求単位で変更する |
| ↓ | Origin Rules | 接続先・Host・ポートなどを変更する |
| ↓ | WAF Custom Rules・Rate limiting・Managed Rules | Block・Challenge・Skipなどを判断する |
| ↓ | Bulk Redirects | 一致すれば転送する |
| ↓ | Managed Transforms・Request Header Transform Rules | 要求ヘッダーを変更する |
| ↓ | Cache Rules | キャッシュ方法を決める |
| 後ろ | Snippets | 短いJavaScriptで要求・応答を処理する |
これは主要な要求フェーズを読者向けに抜粋したものです。実際には他の製品・内部フェーズもあります。最新の順序はCloudflare公式のPhases listで確認してください。
後続ルールの条件式が正しく見えても、前のURL Rewriteでパスが変われば、後続フェーズは変更後の値を評価する場合があります。Traceで途中の値と順序を確認します。
同じフェーズの上書きと終端アクションを確認する
非終端の変更は後のルールが上書きする場合がある
Cloudflare公式のRule evaluationでは、一般に同じフェーズの非終端アクションは後の変更が勝つ場合があると説明されています。期待したルールが一致していても、同じヘッダーや設定を後のルールが変更していないか確認します。
Block・Redirect・Challengeは後続評価を止める
終端アクションが一致すると、その場で処理が終わります。Redirectが複数一致する場合は、最初に一致したRedirectが使われます。後ろに正しいRedirectを追加しても、前の転送が先に一致すれば届きません。
転送が往復している場合は、WordPressのリダイレクトループ確認手順で、WordPress・サーバー・Cloudflareの転送元と転送先を分けてください。
同フェーズ内では変更後の値を次のルール条件で読めない
同じURL Rewriteフェーズでルール1がパスを変えても、ルール2の条件式はルール1が変更した後の値を読みません。同じRequest Header Transformフェーズでも、前のルールが追加したヘッダーを次のルール条件で参照できません。各フェーズ内のフィールド値は評価中に不変だからです。
Request Header Transform Ruleでcf-やx-cf-など変更できないヘッダーを対象にしている場合は、Cloudflare Error 1040の確認手順で、予約ヘッダーと代替手段を確認してください。
後続フェーズで元の値が必要ならrawフィールドを検討する
URL Rewrite後のフェーズで元パスを条件にしたい場合は、raw.http.request.uri.pathなどのrawフィールドを使えるか確認します。rawフィールドは要求評価全体で元の値を保ちます。ただし、既存ルールの意図と対応フィールドを公式資料で確認してから変更してください。
書き換え後のパスが空、先頭スラッシュがない、/cdn-cgi/配下になるなどの問題は、Cloudflare Error 1035の確認手順で、対象ルールと生成後パスを分けて確認します。
動的な書き換え式が値を取得できずError 1037になる場合は、Cloudflare Error 1037の確認手順で、未定義ヘッダー、クエリ、配列要素を分けて確認します。
Skip・Allow・旧Page Rulesの違いを確認する
IP Access AllowとWAF Skipは同じではない
Cloudflare公式のWAF phase interactionsでは、IP Access ruleのAllowが一致すると、後続のWAF Custom Rules、Rate limiting、WAF Managed Rulesなどを迂回する場合があると説明されています。一方、WAF Custom RuleのSkipは、指定した製品・フェーズだけを選択して除外する仕組みです。
特定IPでCustom Ruleが効かずSecurity Eventsにも記録がない場合は、IP Access rulesを確認します。IP Access rulesはCloudflare Traceの結果に表示されないため、Traceだけでは見落とします。
Page Rulesと現行Rules製品を混在させない
Page Rulesは旧方式で、現行Rules製品と同じ要求ビューや順序にならない場合があります。似た転送・キャッシュ設定をPage Rulesと新しいRulesの両方へ置くと、どちらが動いたか分かりにくくなります。移行前後の設定を一覧化し、同じ目的を重複させないようにします。
WordPress固有の条件を確認する
| 対象 | 見落としやすい条件 | 確認すること |
|---|---|---|
| ログイン | POST、ログインCookie、Challenge | /wp-login.phpのGETとPOSTを分ける |
| 管理画面 | 末尾スラッシュ、Cookie、Cache除外 | /wp-admin/と内部リダイレクトを確認 |
| REST API | メソッド、Authorization、JSON Body | /wp-json/と個別エンドポイントを確認 |
| プレビュー | クエリ、ログインCookie | preview関連の条件とCache除外を確認 |
| 検索 | クエリ文字列 | ?s=を含む完全なURLを確認 |
| フォーム | POST Body、Bot・WAF条件 | 表示ページと送信先URLを分ける |
| wp-cron | 外部・内部要求、User-Agent | wp-cron.phpへの要求元を確認 |
公開ページだけでルールを確認すると、更新系の不具合を見落とします。特にCache Rulesやヘッダー変更を広く適用した場合は、ログイン、投稿編集、プレビュー、REST API、フォームを必ず分けて確認してください。
Cloudflare Traceで一致・順序・上書きを確認する
Cloudflare Traceは、指定した要求条件でどの設定が評価・実行されるかをシミュレーションします。URL、メソッド、Cookie、ヘッダー、国などを実際の失敗条件に合わせ、評価順を確認します。
- 正常なURL・条件でTraceを作る
- 失敗するURL・条件で同じTraceを作る
- All configurationsで非一致ルールも表示する
- 最初に結果が分かれたフェーズを探す
- 終端アクションで後ろへ進まなかったか確認する
- 期待ルールの後に同じ値を変えるルールがないか確認する
- Traceに出ないIP Access rulesなどを別画面で確認する
詳しい入力項目、結果の読み方、制限事項は、Cloudflare Traceの使い方で確認できます。Traceを実トラフィック履歴と扱わず、Security Eventsやオリジンログも照合してください。
原因別に一項目だけ修正する
| 原因 | 修正方針 | 修正後の確認 |
|---|---|---|
| DNS only・別ホスト | 正式な対象ホストとProxy statusを見直す | 実応答がCloudflare経由か確認 |
| 条件の不一致 | 実要求値に合わせ、対象を必要範囲へ絞る | 正常・異常URLで一致結果を比較 |
| 前のURL書き換え | 変更後値へ合わせるかrawフィールドを検討 | 前後フェーズのパスを確認 |
| 終端アクション | 先に一致するBlock・Redirect・Challengeの範囲を修正 | 後続フェーズまで到達するか確認 |
| 後続ルールの上書き | 重複目的を統合し、順序と責任を明確にする | 最後の適用値を確認 |
| IP Access Allow・Skip | 必要な製品だけを狭く除外する | Security Eventsと対象IPで確認 |
| Page Rulesとの重複 | 現行Rulesへ整理し、旧設定を段階的に外す | 転送・Cacheの実結果を確認 |
単純な標準Rulesで足りる処理をJavaScriptへ移さず、処理が複雑な場合だけCloudflare Snippets・Workersとの使い分けを確認します。問題を別製品へ移すだけでは、原因は解消しません。
修正後の確認項目
- 対象URLで意図したアクションが実行される
- 対象外URLへルールが広がっていない
- トップ、投稿、固定ページが表示できる
/wp-login.phpの表示とログインができる/wp-admin/で投稿編集・保存ができる- REST APIと外部連携が必要範囲で動く
- プレビュー、検索、フォームが動く
- Cache、転送、応答ヘッダーが意図どおり
- Security Eventsとオリジンログに新しい異常がない
- 正常・異常条件のTrace結果を保存した
- 戻し方と変更内容を記録した
公開ページだけで終えず、管理画面と更新系を確認します。ルールの修正が正しくても、キャッシュに古い応答が残る場合があるため、必要なURLだけを対象に確認し、サイト全体の一括消去を繰り返さないでください。
やってはいけないこと
- 証拠を保存せずルールを削除・上書きする
- DNS、WAF、Cache、Workersを同時に変更する
- Cloudflare全体を長時間停止して回避する
true条件で全URLへ試験ルールを広げる- and・orのまとまりを確認せず条件を追加する
- 前のURL Rewriteを見ず後続ルールだけ直す
- AllowとSkipを同じものとして広い除外を作る
- Traceに出ない設定は存在しないと決めつける
- Page Rulesと現行Rulesに同じ処理を重複させる
- ログイン、REST API、フォームの確認を省く
- 認証情報をスクリーンショットや共有資料へ残す
よくある質問
ルールは一致しているのに結果が変わらないのはなぜですか？
後のルールが同じ値を上書きしている、ブラウザーやCloudflareのキャッシュが古い、実通信がDNS onlyでCloudflareを通っていない、別製品が最終応答を変えている可能性があります。Traceの最後までと実応答を確認してください。
ルールの順番を入れ替えれば直りますか？
同じフェーズ内の順序が原因なら直る場合があります。ただし、製品ごとのフェーズ順は利用者が自由に入れ替えられません。前のフェーズでURLが変わる場合は、後続条件を変更後値へ合わせるかrawフィールドを検討します。
Cloudflare Traceだけで原因を確定できますか？
確定できない場合があります。Traceはシミュレーションで、IP Access rules、Load Balancing、旧機能など結果へ出ない項目があります。実際のSecurity Events、応答ヘッダー、オリジンログと照合してください。
WordPressプラグインを先に停止すべきですか？
Cloudflareの評価順や条件に原因がある証拠がない段階で、プラグインを一括停止しないでください。まずCloudflareへ届く要求とルール結果を確認し、WordPress側の転送・Cache・セキュリティ処理が関係する場合だけ、テスト環境で一つずつ切り分けます。
まとめ
Cloudflare Rulesが効かない原因は、Cloudflareへ届かない、条件に一致しない、先に処理が終わる、後で上書きされる、確認画面に見えない、の5つに分けられます。条件式だけでなく、DNSプロキシ、フェーズ順、終端アクション、Skip・Allow、旧Page Rulesまで確認します。
失敗条件と正常条件を保存し、Traceと実ログで最初に結果が分かれた場所を探してください。原因となる一項目だけを直し、公開ページ、ログイン、管理画面、REST API、フォームまで確認すれば、無関係な防御や速度設定を残したまま復旧できます。