Cloudflareを使っているWordPressで「Error 1040: Invalid request rewrite (header modification not allowed)」が表示されたら、Request Header Transform Ruleが変更できないHTTPリクエストヘッダーを操作しようとしています。
1040は、WordPressのテーマやPHPが直接壊れたことを示すエラーではありません。Cloudflareからオリジンサーバーへ要求を送る前に、保護・制限されているヘッダーのSetまたはRemoveを検出して停止した状態です。
最初にエラー画面、対象URL、発生時刻、Ray ID、直前に変更したRequest Header Transform Ruleを保存してください。その後、ルールが変更しようとするヘッダー名と操作を確認し、制限対象か、別の安全な方法へ変えるべきかを判断します。
先に結論：Error 1040は8段階で確認する
- エラー画面、URL、時刻、Ray ID、HTTPメソッドを保存する
- 直前に追加・変更したRequest Header Transform Ruleを確認する
- Cloudflare Traceで一致するルールと評価順を特定する
- Set static・Set dynamic・Removeの対象ヘッダーを列挙する
cf-・x-cf-、IP・プロトコル識別、Cookieなどの制限を確認する- その変更が本当に必要か、目的から見直す
- 安全な独自ヘッダーまたは適切なCloudflare機能へ分ける
- ログイン、REST API、フォーム、キャッシュ、アクセスログを再確認する
動的な式を評価できない場合は、Cloudflare Error 1037の確認手順を使います。ヘッダー値が長すぎる、または許可されない文字を含む場合は1040ではなく1041として切り分けます。
Cloudflare Error 1040とは？
Cloudflare公式のError 1040では、制限されたHTTPヘッダーを変更しようとしたときのエラーと説明しています。原因は、Request Header Transform Rulesでは変更できないヘッダーを対象にしていることです。
Request Header Transform Ruleは、閲覧者からCloudflareへ届いた要求を、オリジンサーバーへ送る前に調整する機能です。静的値または動的式で値を設定し、既存ヘッダーを上書き・追加するほか、指定ヘッダーを削除できます。ただし、すべてのヘッダーを自由に変更できるわけではありません。
1040・1041・431・400の違い
| 表示 | 主な問題 | 最初に見る場所 |
|---|---|---|
| Cloudflare 1040 | 変更対象のヘッダーが制限されている | ヘッダー名、Set・Remove操作 |
| Cloudflare 1041 | 設定するヘッダー値が不正 | 値の長さ、許可される文字 |
| HTTP 431 | 受信要求のヘッダー全体または一部が大きすぎる | Cookie、認証、Referer、発行元 |
| HTTP 400 | 要求の構文・文字・ヘッダーなどが不正 | エラー発行元、要求内容 |
1040は「値が正しいか」を調べる前に、そのヘッダーをRequest Header Transform Ruleで操作してよいかを確認します。Cookieやヘッダー量が原因の一般的なエラーと混同して、閲覧者のブラウザーデータを先に削除しないでください。
制限1：cf-・x-cf-で始まるヘッダー
Cloudflare公式のRequest Header Transform Rulesでは、名前がx-cf-またはcf-で始まるHTTPリクエストヘッダーは、原則として変更・削除できないと案内しています。
例外としてcf-connecting-ipは削除できますが、例外があるからといって別のcf-*ヘッダーまで変更できるわけではありません。Cloudflareが付与・利用する情報を独自用途で上書きしないでください。
制限2：通信プロトコル上の禁止ヘッダー
プロトコル準拠のため、ブラウザー側で禁止されるヘッダー名をRequest Header Transform Ruleで変更・削除することは一般に許可されません。Cloudflare公式は代表例としてAccept-Encodingを挙げています。
圧縮方式、接続、転送などの動作を変えたい場合は、ヘッダーを無理に上書きするのではなく、その目的に対応するCloudflareの設定機能がないか確認します。機能の役割を越えたヘッダー操作は、1040が消えても別の通信不整合を生むおそれがあります。
制限3：IPアドレスや初期プロトコルを示すヘッダー
x-forwarded-for、true-client-ip、x-real-ip、x-forwarded-protoなど、閲覧者IPや最初の接続プロトコルの識別に広く使われるヘッダー値は変更できません。これらを任意値へ置き換えると、アクセス制御、監査ログ、HTTPS判定の信頼性に影響します。
WordPressやプラグインが送信元IPを必要とする場合は、Cloudflareの正規ヘッダーとサーバー側の復元方法を確認します。「値を合わせるため」と推測で別のIPを入れたり、広い範囲で信頼ヘッダーを書き換えたりしないでください。
制限4：Cookieは設定・変更できない
Request Header Transform Ruleでは、cookieヘッダーの値を設定・変更できません。一方で削除は可能ですが、削除ルールに一致すると同名のCookieヘッダーがすべて削除されます。
CookieのRemoveを1040回避の代替として安易に使わないでください。WordPressのログイン、管理画面、コメント、WooCommerce、会員機能、キャッシュ除外、セキュリティ機能が利用するCookieまで失われる可能性があります。
x-forwarded-forをRemoveしても終わらない
Cloudflare公式では、Request Header Transform Ruleでx-forwarded-forを削除しても、後段のバックエンドプロキシがオリジンへ送る前に閲覧者IPを付け直すと説明しています。削除設定だけを見て、オリジンに届かないと断定できません。
また、同じフェーズのRequest Header Transform Rulesは順番に実行され、後のルールが前の変更を上書きできます。しかし、各ルールのフィルター条件は同フェーズで変更された後の値ではなく、元の要求フィールドを参照します。
修正前に保存する情報
- エラー画面全体、Ray ID、発生時刻、タイムゾーン
- 失敗するURLと成功するURL、HTTPメソッド
- Request Header Transform Ruleの名前、順序、状態
- 一致条件とSet static・Set dynamic・Removeの別
- 変更対象のヘッダー名と、秘密情報を伏せた値・式
- 直前に変更したManaged Transform、Origin Rule、Worker、サーバー設定
- Cloudflare Traceの一致結果と評価順
- オリジンサーバーへ要求が届いたか分かるログ
ルールの目的も一行で記録します。「オリジンへ言語情報を渡す」「特定APIへ識別子を追加する」「Cookieを除外する」など、目的が分かれば、禁止ヘッダーを触らずに別の設計へ移せるか判断しやすくなります。
Cloudflare Traceで原因ルールを特定する
Cloudflare Traceで対象URL、HTTPメソッド、必要なヘッダーなどを指定し、どのRequest Header Transform Ruleが一致するかと評価順を確認します。成功する要求がある場合は、条件を一つずつ変えて比較します。
Traceはシミュレーションであり、過去の本番通信を示す履歴ではありません。実際の発生はRay ID、時刻、実ログと照合します。また、リクエストヘッダーの変更はCloudflareからオリジンへ送る要求へ作用するため、ブラウザーの開発者ツールだけでは変更後の状態を確認できません。
CloudflareのTransform Rules troubleshootingでは、変更後ヘッダーの確認にオリジンサーバーのログまたはTraceを使うよう案内しています。Logpushは元のHTTP要求・応答ヘッダーを記録するため、Transform Ruleによる変更後ヘッダーは含まれない点にも注意します。
原因ヘッダーを一つずつ点検する
1. 操作対象を一覧にする
一つのルールで最大複数のヘッダーを変更できるため、エラー画面だけではどの項目が原因か分からないことがあります。ヘッダー名、操作、静的値または動的式を表にし、制限対象と照合します。
2. ルールの目的から必要性を見直す
同じ情報を独自ヘッダーでオリジンへ渡せるのか、CloudflareのManaged TransformsやOrigin Rulesなど目的に合う機能があるのかを確認します。禁止された名前に似せた別名を作るだけでは、受け取る側の信頼設計が改善しません。
3. 独自ヘッダーは用途を限定する
オリジン内の分類用であれば、既存の保護ヘッダーを上書きせず、用途が分かる独自ヘッダーを検討します。ただし、その値を認証やIP制限の唯一の根拠にせず、外部から同名ヘッダーを送られた場合の扱いもサーバー側で決めます。
4. 複雑な変更は機能の役割を分ける
複雑な条件分岐、署名、認証、サブリクエストを伴う処理は、Request Header Transform Ruleだけで完結させない判断も必要です。Cloudflare公式は複雑なリクエストヘッダー変更にSnippetsを検討するよう案内しています。権限・料金・保守性を確認してから選びます。
WordPressで特に影響を確認する場所
| 場所 | 関係しやすい情報 | 確認すること |
|---|---|---|
| ログイン・管理画面 | Cookie、HTTPS判定 | ログイン維持、リダイレクト、権限 |
| REST API | 認証、Nonce、Content-Type | 取得、保存、外部連携 |
| アクセスログ・防御 | 閲覧者IP、プロトコル | 正しい送信元、遮断条件 |
| キャッシュ | Cookie、独自ヘッダー | ログイン状態、個別表示、除外 |
| フォーム・Webhook | Content-Type、署名、独自ヘッダー | 送信、検証、重複処理 |
ヘッダー変更は画面表示だけでなく、認証、キャッシュ、監査へ影響します。トップページが表示できたことだけで復旧完了にせず、WordPressの管理・保存・外部連携まで確認します。
修正後にWordPressで確認すること
- トップ、投稿、固定ページ、カテゴリー、検索、404が表示できる
- 管理画面へログインし、ログイン状態を維持できる
- 記事の下書き保存、プレビュー、更新ができる
/wp-json/と必要なREST APIが正常な内容を返す- 画像、CSS、JavaScript、サイトマップが取得できる
- フォーム、Webhook、外部APIが重複せず動く
- アクセスログの閲覧者IPとHTTPS判定が想定どおり
- ログイン中ページや会員ページが誤キャッシュされない
- Traceで意図したルールだけが一致する
- 1040が1037、1041、400、401、403、431へ変わっていない
Error 1040が直らないとき
原因ルールを無効化しても1040が続く場合は、別のRequest Header Transform Rule、Managed Transform、対象ゾーン、デプロイ済みバージョンを確認します。ルール名だけでなく、Traceの評価順とRay IDを基準にします。
1040が消えたあとにヘッダー量のエラーが出る場合は、WordPressの431エラー確認手順でCookieや認証ヘッダーを切り分けます。要求全体が不正なら、WordPressの400 Bad Request確認手順へ進みます。
ログインやAPI認証だけ失敗する場合は、WordPressの401 Unauthorized確認手順も使います。ただし、先にCloudflareの1040が消えたことを確認し、複数レイヤーの修正を同時に行わないでください。
よくある質問
ヘッダー名を別名にすれば直りますか？
1040自体は回避できる場合がありますが、目的と安全性の確認が先です。IP、認証、HTTPS判定などの信頼情報を、任意の独自ヘッダーへ移すだけでは安全な設計になりません。
cookieをRemoveすればログイン問題を直せますか？
逆にログイン状態を失う可能性があります。Removeは一致する要求のCookieヘッダーをすべて削除するため、影響範囲を確認せず使わないでください。
1041との違いは何ですか？
1040は変更対象のヘッダーが制限されているエラーです。1041は設定する値が長すぎる、または許可されない文字を含むなど、ヘッダー値の形式が無効なエラーです。
まとめ
Cloudflare Error 1040は、Request Header Transform Ruleが変更できないリクエストヘッダーを操作しようとしたときのエラーです。WordPress本体を先に変更せず、Traceで一致ルールと対象ヘッダーを特定します。
確認の中心は、cf-・x-cf-、プロトコル上の禁止名、IP・初期プロトコル識別用ヘッダー、Cookieの制限です。禁止ヘッダーを別名で模倣するのではなく、変更目的から設計を見直し、認証・ログ・キャッシュまで再確認してください。