Cloudflareを使っているWordPressで「Error 1037: Invalid rewrite rule (failed to evaluate expression)」が表示されたら、Transform Ruleの動的な書き換え式を評価できていません。特定のページ、端末、API、外部サービスからの要求だけで発生することもあります。
1037は、WordPressのPHPやデータベースが直接壊れたことを示すエラーではありません。Cloudflareがオリジンサーバーへ要求を送る前に、式が参照したヘッダーやクエリなどの値を取得できず、書き換え処理を止めた状態です。
最初にエラー画面、対象URL、発生時刻、Ray ID、HTTPメソッド、直前に変更したTransform Ruleを保存してください。その後、成功する要求と失敗する要求をCloudflare Traceで比較し、式が参照する値を一つずつ確認します。
先に結論：Error 1037は8段階で確認する
- エラー画面、URL、時刻、Ray ID、HTTPメソッドを保存する
- 成功する要求と失敗する要求を一つずつ用意する
- 直前に追加・変更したURL Rewrite Ruleを確認する
- Cloudflare Traceで一致するルールと評価順を比べる
- 動的式が参照するヘッダー、クエリ、配列要素を洗い出す
- 未定義のキー、空配列、範囲外の添字を確認する
- ルール条件を絞るか、必要な値がある要求だけで式を実行する
- 公開ページ、管理画面、REST API、検索、外部連携を再確認する
書き換え後のパス自体が空や不正なら、Cloudflare Error 1035の確認手順を使います。出力が長すぎる場合は、Cloudflare Error 1036の確認手順へ切り替えてください。
Cloudflare Error 1037とは？
Cloudflare公式のError 1037では、書き換えルールの式を評価できないときに発生すると説明しています。代表例は、動的式が参照した要素に未定義の値が含まれる場合です。
公式例では、http.request.headers["x-source"][0]を使っているのに、要求にX-Sourceヘッダーがないと1037になります。設定画面で式を保存できても、実際の要求に必要な値がなければ実行時に失敗します。
1035・1036・1040との違い
| エラー | 止まったもの | 最初に見る場所 |
|---|---|---|
| 1035 | 書き換え後URIパスの形式 | 空、先頭スラッシュ、予約パス |
| 1036 | 書き換え後パス・クエリの長さ | 重複連結、動的式の出力 |
| 1037 | 書き換え式の評価 | 未定義値、配列、参照フィールド |
| 1040 | リクエストヘッダーの変更可否 | 予約・制限ヘッダー名 |
1037では「式の結果が間違っている」より前に、式を最後まで計算できたかを確認します。パーマリンク再保存、プラグイン停止、テーマ変更を先に行っても、Cloudflare側の未定義値は直りません。
原因1：参照するヘッダーが要求にない
独自ヘッダーは、特定のアプリ、Webhook、管理ツールだけが送ることがあります。通常のブラウザー、検索エンジン、画像取得、WordPressの内部HTTP要求には同じヘッダーがないため、広いURLへルールを適用すると一部だけ1037になります。
ヘッダー名をマップから取得するときは小文字で指定します。Cloudflareのhttp.request.headersフィールドは、ヘッダー名を小文字へ変換したキーとして扱います。表記ゆれだけでなく、そのキーが実際に存在するかを確認してください。
原因2：配列の0番目が存在しない
http.request.headers["x-source"]は値の配列です。[0]は最初の値を取りますが、ヘッダーがなければ最初の要素もありません。クエリ引数や言語情報など、配列を返す別のフィールドでも同じ考え方が必要です。
Cloudflare Rules languageのValuesでは、存在しないマップキーや配列の範囲外を参照するとmissing valueになると説明しています。関数へmissing valueを渡すと、多くの場合は関数の結果もmissing valueになります。
原因3：対象条件が広すぎる
「すべての受信要求」やホスト名だけを条件にすると、公開記事だけでなく/wp-admin/、/wp-json/、画像、CSS、サイトマップ、Cron、Webhookにも動的式が適用されます。必要な値を持たない要求まで式を実行していないか確認します。
失敗URLの共通点を探してください。特定メソッド、管理パス、検索クエリ、ログイン前だけで起きるなら、WordPress全体の障害ではなく、ルール条件と入力値の組み合わせが原因である可能性が高まります。
原因4：複数ルールと入力の前提がずれている
URL Rewrite Ruleは順番に評価され、後続ルールが前の書き換えを上書きすることがあります。ただし、同じフェーズのフィルター条件は前のルールが変更した値ではなく、元のフィールド値を参照します。「前のルールが値を作るから次の条件で使える」と思い込まないでください。
ルール名、順序、一致条件、PathとQueryのPreserve・Static・Dynamic、式が参照する全フィールドを一覧にします。目的が重複するルールは、どちらが最終結果を担当するかも明確にします。
修正前に保存する情報
- エラー画面全体、Ray ID、発生時刻、タイムゾーン
- 失敗するURLと成功するURL、HTTPメソッド
- ブラウザー、外部サービス、WordPress内部処理など要求元
- URL Rewrite Ruleの名前、順序、状態、最終更新時刻
- 一致条件と動的な書き換え式
- 式が参照するヘッダー、クエリ、Cookie、配列要素
- Cloudflare Traceの成功・失敗条件
- オリジンサーバーへ要求が届いたか分かるログ
式を直す前に現在のルールを記録し、複数箇所を同時に変更しないでください。条件、式、順序を一度に変えると、直った理由と新しい影響範囲が分からなくなります。
Cloudflare Traceで成功・失敗の条件を比べる
Cloudflare Traceは、指定したHTTP要求がCloudflareの設定でどう扱われるかをシミュレーションします。成功する要求と失敗する要求について、URL、メソッド、必要なヘッダーを変えながら、どのTransform Ruleが一致するかを比較します。
Traceは「この条件ならどうなるか」を見る機能で、過去の本番通信を再生するログではありません。実発生の証拠はRay ID、時刻、Cloudflareの実ログ、オリジンログと照合します。オリジンに記録がなくても、Cloudflareで1037が発生していればWordPressへ届いていない可能性があります。
書き換え式を一要素ずつ点検する
1. 参照フィールドをすべて列挙する
式の中から、http.request.headers、URIパス、クエリ引数、Cookie、言語、国情報などの参照を抜き出します。文字列を連結している場合も、連結後だけでなく各入力が存在するかを確認します。
2. has_keyで存在条件を確認する
Cloudflare Rules languageには、マップにキーがあるか確認するhas_key()があります。たとえばhas_key(http.request.headers, "x-source")は、そのヘッダーキーの存在を確認します。動的式がその値を必須とするなら、ルールの一致条件を「値がある要求だけ」に絞れるか検討します。
ただし、条件式の一部だけを機械的に追加せず、ルールの目的と必要なURL・メソッドを先に決めてください。ヘッダーがない通常アクセスを除外してよいのか、別の静的な書き換えが必要なのかで設計が変わります。
3. 配列添字を確認する
[0]、[1]などを使っている箇所を確認します。ヘッダーが存在しても、想定した数の値があるとは限りません。最初の値だけでよいのか、複数値を扱う必要があるのか、公式のフィールド型に合わせます。
4. 小文字キーと入力の実物を確認する
ヘッダーマップのキーは小文字で指定します。設定上の名称だけを見ず、成功・失敗要求で実際に送られているヘッダーと値を確認します。秘密値や認証情報を記録・共有するときは必ず伏せてください。
5. ルールの対象を必要範囲へ絞る
公開記事だけの書き換えなら、管理画面、REST API、ログイン、画像、サイトマップまで同じ式を実行する必要があるか確認します。ホスト、パス、HTTPメソッド、必須ヘッダーの存在を組み合わせ、目的と一致する範囲だけへ適用します。
値がないときの安全な考え方
| 状況 | 検討する対応 | 避けたい対応 |
|---|---|---|
| 値が必須 | 値を送る要求だけに条件を絞る | 存在しない値を無条件で参照 |
| 値が任意 | 値なしの要求は書き換えない、または別ルールに分ける | 一つの複雑な式へ全分岐を詰め込む |
| 要求元ごとに違う | ブラウザー・Webhook・APIを条件で分ける | サイト全体へ同じ前提を適用 |
| 目的が不明 | 無効化前に利用URLと担当機能を調べる | ルールを即削除して影響を広げる |
値がないときに何をするかは、技術だけでなくサイト要件で決まります。「必ずヘッダーを付ける」「値がない要求は元URLを保つ」「別の固定パスへ送る」のどれが正しいか、外部サービスやプラグインの仕様も含めて判断します。
修正後にWordPressで確認すること
- トップ、投稿、固定ページ、カテゴリー、検索、404が表示できる
- 管理画面へログインし、記事を下書き保存できる
/wp-json/と必要なREST APIが正常な内容を返す- 画像、CSS、JavaScript、サイトマップ、robots.txtが取得できる
- ログイン前後、Cookieあり・なしで必要なページが動く
- Webhook、外部API、Cronが重複せず動く
- 必須ヘッダーがある要求とない要求の両方を確認する
- Traceで意図したルールだけが一致する
- 1037が1035、1036、1040、400、404、5xxへ変わっていない
Error 1037が直らないとき
一致ルールを特定できない場合は、URL Rewrite Rules以外のTransform Rule、デプロイ済みバージョン、ルール順序、対象ゾーンが合っているかを確認します。ブラウザーのURLだけでなく、エラー画面のRay IDと発生時刻を基準にします。
式を修正してもWordPressの保存やREST APIだけ失敗する場合は、Cloudflareのエラーが消えたことを確認したうえで、WordPressのJSONレスポンスエラーの確認手順に進みます。1037が残っている段階でWordPress側を一括変更しないでください。
サポートへ相談する場合は、ゾーン、ルール名、ルールID、式、Trace結果、Ray ID、UTCを含む発生時刻、成功・失敗要求の差を整理します。ヘッダー値やCookieに秘密情報が含まれる場合は伏せて共有します。
よくある質問
ルールを保存できたのに1037が出るのはなぜですか？
式の構文が保存時に受け付けられても、実際の要求で参照値が存在するとは限らないためです。成功・失敗要求の入力差を確認してください。
ヘッダーがない場合は空文字になりますか？
一律に空文字として扱わないでください。存在しないマップキーや範囲外の配列要素はmissing valueになります。使う関数や書き換え内容により挙動が変わるため、公式のフィールド型と実要求で確認します。
変更禁止ヘッダーが原因でも1037になりますか？
変更しようとしたヘッダー自体が制限対象なら、主にCloudflare Error 1040の確認手順で切り分けます。1037は式の評価失敗が中心です。
まとめ
Cloudflare Error 1037は、Transform Ruleの書き換え式を実際の要求で評価できなかったときのエラーです。WordPress本体を先に変更せず、成功・失敗要求の差と一致ルールを確認します。
確認の中心は、参照キーが存在するか、配列要素があるか、ヘッダー名が小文字か、対象条件が広すぎないかです。現在の設定を保存し、一項目ずつ直して、通常ページだけでなく管理画面・REST API・外部連携まで再確認してください。