Cloudflareを使っているWordPressで「Error 1036: Invalid request rewrite (maximum length exceeded)」が表示されたら、URL Rewrite Ruleが作ったURIパスまたはクエリ文字列が長すぎます。検索、絞り込み、プレビュー、REST APIなど、元URLが長いときだけ発生する場合もあります。
1036は、閲覧者が送った元URLだけで決まる一般的な414 URI Too Longとは別です。CloudflareのTransform Ruleがパスやクエリを組み立てた結果、許容される長さを超えて停止した状態です。
最初にエラー画面、元URL、発生時刻、Ray ID、直前に変更したURL Rewrite Ruleを保存してください。その後、Cloudflare Traceとルール設定を使い、どの式が何を繰り返し連結したか、不要なクエリを複製していないかを確認します。
先に結論：Error 1036は8段階で確認する
- エラー画面、元URL、時刻、Ray IDを保存する
- 短いURLと長いURLで発生条件を比較する
- 直前に追加・変更したURL Rewrite Ruleを確認する
- Cloudflare Traceで対象URLに一致したルールと順序を確認する
- パスとクエリのどちらが長くなったかを分ける
- 重複連結、不要な複製、全URLの埋め込みを修正する
- 対象条件を必要なホスト・パス・メソッドへ絞る
- WordPressの代表URLと長い入力の境界を再確認する
書き換え後のパスが空、先頭スラッシュなし、/cdn-cgi/配下など形式不正なら、Cloudflare Error 1035の確認手順へ切り替えてください。
Cloudflare Error 1036とは？
Cloudflare公式のError 1036では、書き換え後のURIパスまたはクエリ文字列が許容される最大長を超えたときのエラーと説明しています。解決策は、新しいパスまたはクエリに使う値・式を短くすることです。
URL Rewrite Ruleは、ブラウザーに見えているURLをそのまま転送するだけではありません。静的値や動的式を使い、Cloudflare内部でオリジンへ送るパス・クエリを作り直せます。その式が元の値を二重に足す、長い値を複製する、不要な項目まで引き継ぐと、入力よりはるかに長い結果になります。
1036と414 URI Too Longの違い
| 表示 | 長くなったもの | 最初に見る場所 |
|---|---|---|
| Cloudflare 1036 | Transform Ruleの書き換え結果 | URL Rewrite Rule、動的式、Trace |
| HTTP 414 | クライアントが送ったURI | 元URL、発行元、転送・フォーム設計 |
| Cloudflare 1035 | 長さではなく書き換え後パスの形式 | 空、先頭スラッシュ、予約パス |
| HTTP 431 | Cookieなど要求ヘッダー | Cookie、認証、ヘッダー |
Cloudflare公式の414資料では、クライアントが送ったURIが長すぎる場合のエラーで、CloudflareはURIが32KBを超えると414を生成すると案内しています。1036は、元URLがその値に達していなくても、書き換え結果が膨らむことで発生し得ます。
ブラウザーの元URL自体が長い、POST内容をGETへ変換した、リダイレクトのたびにクエリが増える場合は、WordPressの414 URI Too Longを直す手順で入力側から確認します。
WordPressで1036が出る主な原因
1．元のパスを二重に連結している
動的式で固定の接頭辞を付けるつもりが、元のhttp.request.uri.pathを複数回入れると、投稿スラッグや階層がそのまま重複します。短いトップページでは気付かず、長い投稿URLだけ1036になることがあります。
2．パスへ完全なURLを埋め込んでいる
必要なのはURIパスなのに、スキーム、ホスト名、パス、クエリを含む完全なURLを何重にも埋め込むと、結果が急激に長くなります。URL Rewrite Ruleではホスト名を書き換えられないため、接続先変更の要件とパス変更を分けます。
3．クエリ文字列を重複して引き継いでいる
検索語、絞り込み、計測パラメータ、プレビュー情報などを維持する際、元クエリを残したまま同じ値を式で追加すると重複します。クエリを変更しないならPreserveを使い、変更するなら必要なキーだけを再構成します。
4．複数のルールが同じ値を追加している
言語、端末、キャッシュ、画像配信用など複数のURL Rewrite Ruleが同じURLに一致すると、後続ルールが前の結果を上書きします。ルールごとの目的が重なり、最終的に長い値を作っていないか、評価順と対象条件を確認します。
5．すべての受信要求を対象にしている
公開ページ用のルールが/wp-admin/、/wp-json/、検索、サイトマップ、画像、プレビューにも適用されると、元から長い管理用クエリへ追加処理が重なります。守るべき範囲ではなく、書き換えが必要な範囲へ条件を絞ります。
6．エンコード済みの値を繰り返し加工している
日本語検索語、戻り先URL、外部連携の値などは、URL上でパーセントエンコードされると見た目より長くなります。元の文字数だけで判断せず、実際にCloudflareへ届いたURLと式が作る結果を確認します。
4096文字の設定上限と1036を混同しない
Cloudflare公式のURL rewrite parametersでは、一つのURL Rewrite Ruleに設定するパラメータ値の合計上限を4,096文字としています。たとえばパスの静的値・式とクエリの静的値・式を合わせた設定内容の長さです。
これは、すべての書き換え後URLが4,096文字で1036になるという説明ではありません。動的式は入力によって異なる結果を作ります。1036の公式ページは書き換え後のパスまたはクエリが最大長を超えた状態と説明していますが、記事作成時点で一律の実行結果上限値は示していません。推測の数値で安全判定せず、実際の入力と出力を短くします。
変更前に保存する情報
- エラー画面全体、Ray ID、発生時刻、タイムゾーン
- 失敗した元URL。秘密情報は伏せて保存する
- 成功する短いURLと失敗する長いURL
- パス長、クエリ長、クエリ項目数の比較
- URL Rewrite Ruleの名前、順序、状態、更新時刻
- PathとQueryのPreserve・Static・Dynamic
- 静的値、動的式、ワイルドカード置換
- 直前に変更したルール、プラグイン、検索・計測設定
元URLにnonce、トークン、検索語、メールアドレスなどが含まれる場合、公開掲示板へ貼らないでください。再現用URLは秘密情報を伏せ、本番の保存・決済・送信操作を繰り返さず調査します。
Cloudflare Traceで膨らむルールを探す
Cloudflare Traceへ成功する短いURLと失敗する長いURLの条件を入れ、Transform Rulesの一致結果と評価順を比較します。どちらにも一致するルール、長い入力でだけ一致するルール、後ろから上書きするルールを分けます。
Traceはシミュレーションなので、実発生の履歴はRay ID、発生時刻、Cloudflareログと照合します。1036ではオリジンへ要求が届かないことがあるため、オリジンログに記録がないことだけでWordPress側の障害と判断しません。
| 比較項目 | 短いURL | 失敗URLで見る点 |
|---|---|---|
| 元のパス | 階層・スラッグが短い | 同じ部分が複数回現れないか |
| 元のクエリ | 項目が少ない | 同じキー・値が重複していないか |
| 一致ルール | 対象外または一つ | 複数ルールが一致していないか |
| 動的式 | 出力が短い | 完全URLや元値を複製していないか |
式を短くする安全な考え方
1．元の値を一度だけ使う
動的式の中でhttp.request.uri.pathやクエリを何回参照しているか数えます。接頭辞または接尾辞を追加する場合も、元の値を一度だけ連結する形へ整理します。
2．変更不要な側はPreserveにする
パスだけを変更するならクエリはPreserve、クエリだけを変更するならパスはPreserveにします。両方へ似た式を置くと、完全URLやクエリを誤って二重に持たせる原因になります。
3．必要な値だけを残す
すべてのクエリ項目を無条件に複製せず、WordPressや外部連携が本当に必要とする項目を確認します。ただし、認証、プレビュー、フォーム、計測に必要な値を推測で削除すると別の不具合になるため、担当機能とテストを用意してから変更します。
4．ルールの対象を狭める
書き換えが必要なのが公開記事だけなら、管理画面、REST API、画像、サイトマップなどを対象から外せるか確認します。特定のホスト、パス、HTTPメソッドへ限定し、長い管理用URLまで加工しない設計にします。
5．複数ルールを一つずつ検証する
後のURL Rewrite Ruleは前の変更を上書きできますが、同じphase内のフィルター式は元のフィールド値で評価されます。ルールを一括で並べ替えず、対象URLに対する一致結果と最終動作を一つずつ確認します。
修正後にWordPressで確認すること
- トップ、短い投稿URL、長い投稿URLが表示できる
- 検索語が短い場合と長い場合で結果が正常に返る
- カテゴリー、タグ、ページ送り、絞り込みが動く
- 管理画面へログインし、記事を下書き保存できる
- REST API、プレビュー、フォーム、Webhookが動く
- 画像、CSS、JavaScript、サイトマップが取得できる
- Traceで意図したルールだけが一致する
- 1036が1035、414、400、404、5xxへ変わっていない
URL書き換えで/wp-json/や投稿保存の要求が崩れた場合は、WordPressの正しいJSONレスポンスではないエラーも確認します。1036が消えただけで完了にせず、保存結果とレスポンス内容を確認してください。
やってはいけない対処
- 証拠を残さずTransform Rulesをすべて削除する
- Cloudflareのプロキシを恒久的に外して回避する
- 推測の上限値だけを基準に安全と判断する
- 元のパスやクエリを複数回連結する
- 必要性を確認せずクエリ項目をすべて削除する
- 式、ルール順序、WordPress設定を同時に変える
- トークン入りURLや個人情報を公開する
- 投稿保存、決済、フォーム送信を連打して再現する
よくある質問
WordPressのパーマリンクを短くすれば直りますか？
一部のURLは短くなりますが、根本原因が重複連結やクエリ複製なら再発します。先にURL Rewrite Ruleが元の値を何回使い、どの出力を作っているか確認してください。
4096文字未満なら1036は出ませんか？
そのようには断定できません。4,096文字は公式資料で示されたルール設定パラメータ値の合計上限です。動的に生成された書き換え結果の一律上限として扱わず、不要な連結をなくして実際の結果を短くします。
閲覧者側で直せますか？
基本的にはサイト運営者がCloudflareのルールを修正する必要があります。閲覧者はエラー画面、URL、Ray ID、発生時刻を運営者へ伝え、検索や送信を何度も繰り返さないでください。
まとめ
Cloudflare Error 1036は、URL Rewrite Ruleが作ったURIパスまたはクエリ文字列が長すぎるときのエラーです。元URLの長さだけでなく、Cloudflare内部の式が作る最終結果を確認します。
復旧の中心は、元値の二重連結、完全URLの埋め込み、クエリの重複、広すぎる対象条件をなくすことです。1036と414・1035を分け、短いURLと長いURLを比較しながら一項目ずつ修正してください。