Cloudflareを使っているWordPressで「Error 1041: Invalid request rewrite (header value invalid)」が表示されたら、Request Header Transform Ruleが設定しようとするHTTPリクエストヘッダーの値を確認します。
1041は、WordPressのテーマやPHPが直接壊れたことを示すエラーではありません。Cloudflareからオリジンサーバーへ要求を送る前に、長すぎる値または使用できない文字を含む値を検出して、書き換えを停止した状態です。
最初にエラー画面、対象URL、発生時刻、Ray ID、直前に変更したRequest Header Transform Ruleを保存してください。そのうえで、ルールの式だけではなく、実際の要求から最終的に生成されるヘッダー値を調べます。
先に結論：Error 1041は8段階で確認する
- エラー画面、URL、時刻、Ray ID、HTTPメソッドを保存する
- 直前に追加・変更したRequest Header Transform Ruleを確認する
- Cloudflare Traceで一致するルールと評価順を特定する
- Set staticかSet dynamicか、対象ヘッダー名と値を整理する
- 生成後の値が4KBを超えていないか確認する
- 改行、制御文字、日本語など使用できない文字がないか確認する
- 短いASCII値へ最小修正し、狭い条件で検証する
- WordPressのログイン、REST API、フォーム、キャッシュを確認する
変更できないヘッダーを操作している場合は、Cloudflare Error 1040の確認手順へ進みます。動的な式そのものを評価できない場合は、Cloudflare Error 1037の確認手順で切り分けてください。
Cloudflare Error 1041とは？
Cloudflare公式のError 1041では、追加または変更しようとしたヘッダー値が無効な場合に発生すると説明しています。主な原因は、値が長すぎること、または許可されない文字が含まれることです。
Request Header Transform Ruleは、閲覧者からCloudflareへ届いた要求をオリジンサーバーへ送る前に調整します。静的な文字列を設定するSet staticと、要求の情報から値を作るSet dynamicがあります。1041では、ヘッダー名よりも設定される値の中身が主な確認対象です。
1041・1040・1037・431の違い
| 表示 | 主な問題 | 最初に見る場所 |
|---|---|---|
| Cloudflare 1041 | 設定するヘッダー値が無効 | 値の長さ、文字、動的式の結果 |
| Cloudflare 1040 | 変更対象のヘッダーが制限されている | ヘッダー名、Set・Remove操作 |
| Cloudflare 1037 | 書き換え式を評価できない | 式、参照フィールド、型、条件 |
| HTTP 431 | 受信した要求ヘッダー全体または一部が大きすぎる | Cookie、認証、Referer、要求元 |
1041の4KB上限は、Transform Ruleで設定する一つのヘッダー値について確認する基準です。閲覧者から届くCookieや複数ヘッダーを含む要求全体の問題とは分けます。Cookieを消せば直ると考えて、利用者のブラウザーデータを先に削除しないでください。
原因1：ヘッダー値が4KBを超えている
Cloudflare公式のヘッダー形式では、ヘッダー値の最大サイズを4KBとしています。おおよそ4,096バイトですが、文字数とバイト数を同じものとして扱わず、生成後の実データで確認します。
固定の短い識別子なら上限へ届きにくい一方、URL、クエリー文字列、User-Agent、Referer、Cookie、JSON断片などを連結すると急に長くなります。特に「調査用だから」と要求情報を丸ごと独自ヘッダーへ詰め込む設定は避けてください。
動的な値は要求ごとに長さが変わる
Set dynamicでは、同じルールでもアクセスするURL、クエリー、Cookie、利用端末などによって結果が変わります。トップページでは成功しても、検索URL、プレビュー、管理画面、長いパラメーターを持つ外部連携だけ1041になることがあります。
成功するURLと失敗するURLを一つずつ用意し、どの入力が値を膨らませるのか比較します。値の途中だけを切り取って上限へ収めると識別子の衝突や署名不一致を起こす場合があるため、目的に必要な短い情報だけを作り直すほうが安全です。
原因2：使用できない文字が含まれている
Cloudflareの形式資料では、ヘッダー値に使用できるASCIIの英数字と記号を示しています。日本語などの非ASCII文字、改行、タブ以外の制御文字、コピー時に混ざった不可視文字などは、そのまま設定しないでください。
たとえば管理用メモの「会員ページ」や、フォームから受け取った氏名・住所を独自ヘッダーへ直接入れる設計は適切ではありません。文字形式の問題だけでなく、個人情報がオリジンログや外部サービスへ残る危険もあります。用途を示す短い英数字のコードへ置き換えます。
改行を含む貼り付け値に注意する
複数行の設定、テンプレート、表計算ソフトから値を貼り付けると、末尾の改行や見えない文字が混ざる場合があります。目視だけで判断せず、値を短い半角英数字へ一度置き換えて再現するか確認します。
原因3：複数ルールの結果が重なっている
Request Header Transform Rulesの公式資料では、ルールは順番に実行され、後のルールが同じヘッダーへの前の変更を上書きできると説明しています。似た名前のルールが複数ある場合は、一つだけを見て原因なしと判断できません。
また、動的な値が空または未定義になり、対象ヘッダーが既に存在すると削除されるなど、条件によって結果が変わる仕様があります。ルール名、順序、条件、操作、対象ヘッダー、値または式を一覧にして確認します。
修正前に保存する情報
- エラー画面全体、Ray ID、発生時刻、タイムゾーン
- 失敗するURLと成功するURL、HTTPメソッド
- Request Header Transform Ruleの名前、順序、有効状態
- 一致条件とSet static・Set dynamicの別
- 対象ヘッダー名と、秘密情報を伏せた値・式
- 入力によって変わるURL、クエリー、Cookie、User-Agentなど
- Cloudflare Traceの一致結果と評価順
- オリジンサーバーへ要求が届いたか分かるログ
ヘッダー値にトークン、認証情報、Cookie、メールアドレスなどが含まれる場合は、スクリーンショットや問い合わせ文へそのまま載せません。先頭と末尾の一部、長さ、文字種だけを残して伏せます。
Cloudflare Traceと設定画面で原因を特定する
Cloudflare Traceで対象URL、HTTPメソッド、必要なリクエスト情報を指定し、どのRequest Header Transform Ruleが一致するか、どの順番で評価されるかを確認します。成功例と失敗例で条件を変え、結果を比較してください。
Traceは指定した条件に対するシミュレーションで、過去の本番アクセスを保存したログではありません。実際の障害はRay ID、発生時刻、オリジンログと照合します。動的値へCookieなどを参照する場合も、秘密情報を入力・共有する範囲を最小限にします。
Transform Rulesのトラブルシューティングでは、変更後のリクエストヘッダーはブラウザーではなく、オリジンサーバーのログやTraceで確認するよう案内しています。Logpushに記録される要求ヘッダーはTransform Rule適用前の情報であるため、変更後の値だと思い込まないでください。
安全な修正方法
1. 値の目的を一文で決める
「会員ページかどうかをオリジンへ伝える」「特定APIの経路を分類する」のように目的を一つへ絞ります。デバッグ、認証、分析、個人識別を一つの長いヘッダーへまとめないでください。
2. 短いASCII値へ置き換える
管理用の分類なら、たとえば短い英数字とハイフンなど、公式形式に収まる値を使います。日本語の説明文はCloudflareのルール説明欄や運用資料へ残し、実際のヘッダー値へ入れません。
3. 動的入力を丸ごと連結しない
完全なURL、Cookie全体、User-Agent全体、フォーム入力をそのまま値へ連結しません。必要な分類結果だけを短いコードにするか、ログで確認すべき情報はオリジン側の既存ログへ分けます。
4. 条件を狭くして検証する
サイト全体へ適用する前に、テスト用URLや限定したパスで確認します。複数ルールを同時に変更せず、原因候補を一つ修正するたびにTraceと実アクセスを比較します。
やってはいけない対処
- 原因を記録せずルールをまとめて削除する
- 4KB以内にするため意味のある値を途中で機械的に切る
- 日本語やフォーム入力を別の独自ヘッダーへそのまま移す
- 認証トークン、Cookie、個人情報を検証用ヘッダーへ複製する
- サイト全体の条件へ変更し、ログインや管理画面まで巻き込む
- ブラウザーに見える要求だけでCloudflare適用後の値を判断する
- 1041と無関係なプラグインやテーマを先に削除する
エラーを消すためだけにヘッダー値を別の場所へ複製しないでください。秘密情報や個人情報の露出範囲を広げると、1041より深刻な問題になります。短い分類値で目的を満たせない場合は、処理の設計自体を見直します。
修正後にWordPressで確認すること
- トップ、投稿、固定ページ、カテゴリー、検索、404が表示できる
- 管理画面へログインし、ログイン状態を維持できる
- 記事の下書き保存、プレビュー、更新ができる
/wp-json/と必要なREST APIが正常な内容を返す- 画像、CSS、JavaScript、サイトマップが取得できる
- フォーム、Webhook、外部APIが重複せず動く
- キャッシュ対象と除外対象が意図どおり分かれる
- オリジンログに必要な短い値だけが届いている
- 成功URLと以前失敗したURLの両方が通る
- 1041が1040、1037、400、401、403、431へ変わっていない
Error 1041が直らないとき
原因候補のルールを無効化しても1041が続く場合は、別のRequest Header Transform Rule、対象ゾーン、ルールの公開状態、後続ルールを確認します。設定画面の名前だけでなく、Traceの一致結果と順序を基準にしてください。
1041が消えた後に要求ヘッダーの大きさを示す431が出る場合は、WordPressの431エラー確認手順でCookieや認証ヘッダーを調べます。一般的な不正要求へ変わった場合は、WordPressの400 Bad Request確認手順を使います。
Cloudflareへ問い合わせる場合は、Ray ID、時刻とタイムゾーン、対象URL、HTTPメソッド、ゾーン、ルール名、Trace結果、秘密情報を伏せた式と値の長さをまとめます。値そのものを無加工で送る必要があるかは、サポートの安全な提出方法を確認してください。
よくある質問
4KB以内ならどの文字でも使えますか？
いいえ。長さだけでなく、Cloudflareが示すヘッダー値の文字形式にも合わせる必要があります。非ASCII文字、改行、不可視文字が混ざっていないか確認してください。
日本語をURLエンコードすれば使えますか？
形式上通る可能性だけで判断しません。受け取るオリジンが同じ方式で安全に復元できるか、値が4KBを超えないか、個人情報を含まないかを確認します。分類用途なら短い英数字コードのほうが管理しやすくなります。
ブラウザーの開発者ツールで変更後の値を確認できますか？
通常は確認できません。Request Header Transform RuleはCloudflareからオリジンへ送る要求へ作用するため、Traceまたは秘密情報を適切に伏せたオリジンログで確認します。
まとめ
Cloudflare Error 1041は、Request Header Transform Ruleで設定する値が長すぎる、または使用できない文字を含むときのエラーです。WordPress本体を先に変更せず、Ray IDと時刻を保存し、Traceで原因ルールを絞ります。
最終的に生成される値を4KB上限と許可文字へ照合し、短いASCII値へ最小修正してください。復旧後は公開ページだけでなく、ログイン、記事保存、REST API、フォーム、キャッシュ、オリジンログまで確認すれば、エラーだけを隠して別の不具合を残すのを防げます。