WordPressの公開ページ、ログイン画面、管理画面、記事保存、REST APIで「431 Request Header Fields Too Large」と表示されることがあります。URLは短く、アップロードファイルも小さいのに、特定のブラウザやログイン中だけ開けない症状です。
431は、ブラウザなどが送るHTTP要求ヘッダー全体、またはCookieやAuthorizationなど一つのヘッダーフィールドが、受信側の許容サイズを超えた状態です。要求本文の容量やURLの長さとは確認箇所が異なります。
最初からサーバー上限を大きくしたり、Cookieや認証ヘッダーの中身を公開チャットへ貼ったりしないでください。ヘッダーにはログイン情報、セッショントークン、参照元URLなどが含まれます。秘密値を見せずに大きい項目を特定し、生成元を直すことが先です。
先に結論：431エラーは8段階で確認する
- 編集中の本文やフォーム入力を別の安全な場所へ退避する
- 操作、時刻、URL、ログイン状態、431を記録する
- 別ブラウザまたはプライベートウィンドウで、閲覧だけを比較する
- 特定ブラウザ・ログイン中だけなら、対象サイトのCookieを疑う
- Network欄でヘッダー名と概算サイズを確認し、値は共有しない
- CDN・WAF・プロキシ・Webサーバーのどこが拒否したか特定する
- Cookieや独自ヘッダーの生成元を一か所だけ修正する
- 必要性を確認できた場合だけ、管理者が受信上限を最小限調整する
URLそのものが長い場合はWordPressの414 URI Too Longを直す確認順、番号が400でCookieやヘッダーを含む要求全体を調べる場合はWordPressの400 Bad Requestを直す確認順を使ってください。
431 Request Header Fields Too Largeとは？
RFC 6585の431 Request Header Fields Too Largeは、要求ヘッダーが大きすぎるため、サーバーが処理を拒否する状態です。ヘッダー全体が大きい場合と、一つのヘッダーフィールドだけが大きい場合の両方に使えます。
応答側が原因となる一項目を特定できる場合、どのフィールドが大きいかを示すことが推奨されています。また、431応答はキャッシュへ保存してはいけないと定められています。修正後も同じ表示なら、まず本当に同じ要求が再送されているかを確認します。
HTTPには、すべての環境に共通する一律のヘッダー長上限がありません。ブラウザ、CDN、WAF、リバースプロキシ、Webサーバー、アプリケーションが、それぞれ異なる制限を持ちます。最も小さい制限に達した層が先に拒否します。
WordPressが常に431を生成するわけでもありません。WordPressに同梱されるHTTPクライアントは外部サービスからの431を識別できますが、閲覧時の431はWordPressへ届く前にCDNやWebサーバーが返している場合があります。Nginxの公式仕様では、一つの要求ヘッダーフィールドがバッファを超えると400になります。
400・413・414・431の違い
| 表示 | 主な意味 | 最初に見るもの |
|---|---|---|
| 400 Bad Request | 要求の構文や内容を処理できない | URL、Cookie、ヘッダー、本文全般 |
| 413 Content Too Large | 要求本文が大きすぎる | 画像、ファイル、POST本文 |
| 414 URI Too Long | 要求先URIが長すぎる | パス、クエリ文字列、転送先URL |
| 431 Request Header Fields Too Large | 要求ヘッダー全体または一項目が大きすぎる | Cookie、Authorization、Referer、独自ヘッダー |
画像アップロードのファイルサイズが原因なら、ヘッダーではなく要求本文を扱うWordPressの413 Content Too Largeを直す確認順が適切です。画面の文言だけでなく、ブラウザのNetwork欄で実際のHTTPステータスを見て分けます。
WordPressで431またはヘッダー過大になる主な原因
1．同じドメインのCookieが増えすぎている
WordPressはログインや管理画面の状態にCookieを使います。さらに、テーマ、プラグイン、アクセス解析、広告、会員、EC、多言語、ABテストなどが独自Cookieを追加すると、ブラウザが同じサイトへ送るCookieヘッダーが膨らみます。
Cookie名が違っていても、対象ドメインとパスが同じなら一つの要求へ多数含まれます。古い版と新しい版、wwwあり・なし、サブドメイン共有、パス違いのCookieが重複して残る場合もあります。
2．認証・セッション情報が大きすぎる
Authorization、独自セッショントークン、署名付きの値に、多数の権限、属性、グループ情報を詰め込むと、一項目だけで上限へ達することがあります。外部ログイン、会員管理、CDN認証、開発用ツールの導入後に始まった場合は優先して確認します。
トークンを途中で切れば短くなりますが、署名や認証が壊れます。値を手編集せず、発行元の設定、含める情報、保存方式、有効期限を見直します。
3．Refererへ長いURLが入っている
直前ページのURLが長いと、遷移先への要求にRefererとして含まれる場合があります。多数の検索条件、計測値、redirect_to、長い管理画面URLを持つページから移動したときだけ失敗するなら候補です。
Refererを無条件に削除すると、セキュリティ確認、分析、外部連携へ影響することがあります。まず長いURLを生成したフォームや転送処理を確認し、必要な情報だけを残します。
4．プラグインや外部連携が独自ヘッダーを重複追加している
JavaScript、プラグイン、CDN Worker、リバースプロキシが、追跡ID、端末情報、権限、署名、転送元情報を独自ヘッダーへ追加することがあります。同じ処理が二重に読み込まれると、同名フィールドや似た情報が重複します。
更新後に始まった場合は、追加されたヘッダー名、どの層で増えたか、送信先が本当に必要としているかを確認します。値そのものを公開せず、項目名とサイズの変化だけを比較します。
5．CDN・WAF・Webサーバーの上限が異なる
同じ要求でも、CDNは受け付け、オリジンサーバーだけが拒否する場合があります。逆に、WordPressのアクセスログへ何も残らず、CDNやWAFで止まる場合もあります。一層の上限だけを変えても、別の小さい上限に当たれば解決しません。
HTTP/2やHTTP/3では転送時にヘッダー圧縮がありますが、受信側の制限判断は圧縮前の意味上のサイズを基準にする実装があります。「通信上は圧縮されるから大丈夫」とは考えず、利用サービスの公式仕様を確認してください。
6．異常な要求や攻撃を防御層が拒否している
非常に大きいCookie、Authorization、重複ヘッダーは、要求スマグリングやリソース消費を狙う異常通信として扱われることがあります。特定の自分のブラウザだけでなく、多数の送信元から急増している場合は、防御を弱めずセキュリティイベントを確認します。
最初の10分で行う安全な初動
1．入力内容を退避し、発生条件を記録する
記事本文、商品情報、フォーム入力などを安全な場所へコピーします。次に、発生時刻、URL、操作、HTTPメソッド、ログイン状態、ブラウザ、431または実際の番号を記録します。CookieやAuthorizationの値は記録表へ貼らないでください。
トップページ、管理画面、特定ページ、保存操作のどこで出るかも分けます。サイト全体で出るのか、ログイン中だけか、ある長いURLから移動したときだけかで、優先するヘッダーが変わります。
2．閲覧だけを別の状態で比較する
公開ページの閲覧であれば、別ブラウザやプライベートウィンドウから同じURLを開きます。通常ブラウザだけ失敗するなら、そのプロファイルに保存されたCookieや拡張機能が有力です。どの環境でも失敗するなら、サーバー側や共通の転送・ヘッダー生成を疑います。
更新、決済、送信、削除を伴う操作をプライベートウィンドウで再現しないでください。認証状態やnonceが変わり、別のエラーや重複処理を起こします。状態を変えるテストは、テスト環境とテストデータで行います。
3．Network欄では値でなく項目名と大きさを見る
ブラウザの開発者ツールで失敗した要求を選び、Request Headersを確認します。Cookie、Authorization、Referer、独自のX-系フィールドなど、長そうな項目を特定します。サポートへ伝えるときは、値を[伏せ字]にし、文字数やバイト数の目安だけを共有します。
HARファイルにはCookieやトークンが含まれる場合があります。公開チャットや不特定多数が見られる場所へアップロードせず、必要なら信頼できるサポート窓口の安全な提出方法を確認してください。
どの層が431またはヘッダー過大を返したか特定する
| 確認層 | 見るもの | 判断の手がかり |
|---|---|---|
| ブラウザ | Cookie、Referer、拡張機能、プロファイル差 | 特定ブラウザやログイン中だけ失敗するか |
| CDN・WAF | 応答ヘッダー、イベント、リクエストID | オリジン到達前に拒否したか |
| リバースプロキシ | 転送前後のヘッダー名・概算サイズ | 転送情報や認証値を追加したか |
| Apache・Nginx | アクセスログ、エラーログ、ヘッダー制限 | 単一項目または全体が上限を超えたか |
| WordPress・外部API | プラグインログ、HTTPクライアント応答 | 独自処理や外部サービスが返したか |
Nginxのlarge_client_header_buffersでは、一つの要求行が一つのバッファを超えると414、一つの要求ヘッダーフィールドが超えると400を返すと説明されています。ヘッダー過大でも必ず431になるわけではありません。
ApacheのLimitRequestFieldSizeは、一つの要求ヘッダーフィールドで許容するバイト数を設定します。公式資料は、通常の条件では既定値を変更すべきでないと注意しています。
保存時にJSON以外のエラーページへ置き換わり、「返答が正しいJSONレスポンスではありません」も出る場合は、WordPressのJSONレスポンスエラーを直す手順も使い、実際の応答本文と発行元を確認してください。
原因別の安全な直し方
1．対象サイトのCookieだけを整理する
特定ブラウザだけ失敗し、Cookieが原因と判断できた場合は、編集中の内容と必要なログイン情報を退避してから、対象ドメインのCookieだけを削除します。削除するとログアウトし、カート、表示設定、一時入力が失われる場合があります。
ブラウザ全体の履歴や全サイトデータまで消す必要はありません。対象サイトのCookie削除で一時的に直っても、再び増えるなら、テーマ・プラグイン・外部サービスが重複Cookieを発行していないかを調べます。
WordPress公式のCookies資料では、認証用、ログイン状態、管理画面設定、コメント等に使うCookieが説明されています。必要なWordPress Cookieを名称だけで削除対象と決めず、発行元と用途を確認します。
2．Cookieのドメイン・パス・寿命を適切に絞る
独自Cookieは、必要なサブドメインとパスだけへ送るようにします。管理画面だけで使う値をサイト全体へ送る、サブドメイン共有が不要なのに親ドメインへ設定する、古いCookieを別名で残し続ける、といった状態を避けます。
値へ大きな設定JSONや履歴を保存せず、サーバー側の状態を参照する短い識別子にできるか検討します。ただし、認証Cookieの構造を独自に書き換えず、WordPressやプラグインの正式な仕組みを使ってください。
3．認証・独自ヘッダーの内容を必要最小限にする
Authorizationや署名付きトークンに、利用しない属性、巨大な権限一覧、重複情報を含めていないか確認します。認証方式の変更はセキュリティに直結するため、外部サービスやプラグインの公式仕様に従い、テスト環境で検証します。
ログインできない症状を伴う場合は、WordPressの401 Unauthorizedを直す確認順も参照し、Cookie認証、Basic認証、Application Password等を混同しないでください。
4．Refererと転送URLを短くする
長いRefererが原因なら、検索条件、計測パラメータ、redirect_toが増殖した元ページを直します。Refererだけを隠して症状を消すより、長いURLの生成と転送を整理したほうが、ログや共有URLの安全性も改善します。
転送のたびに元URLが埋め込まれている場合は、WordPressのリダイレクトループを直す手順でLocationを順に確認し、URLを追加する担当を一つに絞ります。
5．CDN・プロキシが追加する情報を整理する
転送元IP、地域、端末、認証、追跡情報を複数層が重複追加していないか確認します。オリジンが使わない独自フィールドは、提供元の仕様とセキュリティ担当の判断に基づいて削減します。
CDN側とオリジン側で許容サイズが異なる場合は、通常の正規要求が両方を通る範囲にそろえます。上限だけでなく、監視、拒否ログ、異常要求への防御を維持します。
6．サーバー上限は最後に必要最小限で調整する
正常な認証や業務連携に必要なヘッダーが、合理的に減らしても上限を超える場合だけ、サーバー会社または管理者へ相談します。単一フィールドとヘッダー全体のどちらが不足しているか、CDN・プロキシ・Webサーバーの値を確認します。
上限を極端に大きくすると、異常要求を受け入れる範囲とメモリ消費が増えます。現在値、必要な実測値、安全な余裕、戻し方、監視方法をそろえ、一層ずつ変更します。共有サーバーでは自分で変更できない場合があります。
やってはいけない対処
- Cookie、Authorization、nonce、トークンを公開の相談先へ貼る
- 秘密値を外部のオンライン解析サイトへ入力する
- 原因を見ず、ブラウザ全体の全Cookieを削除する
- 認証トークンやCookie値を途中で切って短くする
- Cookie認証、WAF、REST APIをまとめて無効化する
- CDN、プロキシ、Apache・Nginxの上限を同時に変える
- 要求ヘッダー上限を無制限または極端に大きくする
- 本番の保存、注文、送信を何度も再実行する
Cookie削除は、特定ブラウザに残った肥大データを消す初動にはなりますが、再発する場合の根本解決ではありません。どの機能が何を発行したかまで確認し、正常な利用で再び上限へ達しない設計にします。
復旧後の確認チェックリスト
- 公開ページ、ログイン、管理画面が意図した応答になる
- 問題の保存・フォーム操作が一度で完了する
- 通常ブラウザと別ブラウザの両方で再発しない
- Cookieがページ移動のたびに増殖しない
- 同名・旧版・不要なCookieが再作成されない
- Authorizationと独自ヘッダーが必要な情報だけを含む
- 長いRefererやredirect_toが繰り返し増えない
- CDNとオリジンのログで4xxが増え続けていない
- WAFと認証の保護が有効なままである
- 一時的に広げた上限やデバッグログを見直した
公開URLが431または別の4xxを返し続けると、読者だけでなく検索クローラーも内容を取得できません。GoogleのHTTPステータスコード解説では、429を除く4xxを返すURLを検索処理上「内容が存在しない」ものとして扱い、既存URLはインデックスから除かれ得ると説明しています。主要公開ページが200を返すことも確認します。
自力で直せないときに伝える情報
- 発生日時とタイムゾーン
- 対象URL、操作、HTTPメソッド、実際のステータス
- ログイン中・ログアウト中・別ブラウザでの違い
- 秘密値を伏せたヘッダー名と概算サイズ
- Cookie全体か、Authorization等の一項目か
- CDN・WAFのリクエストIDとオリジン到達有無
- Apache・Nginx等の種類と変更可能な契約範囲
- 直前に更新したプラグイン、認証、CDN設定
- すでに試した一変更と結果
共有前にCookieと認証値を必ず伏せ、HARファイルの提出は安全な窓口が指定した場合だけにします。WordPressへ到達していなければサーバー会社やCDN、独自ヘッダーが原因ならプラグイン・連携サービスの開発元へ相談します。
よくある質問
431はCookieを消せば必ず直りますか？
Cookieが原因なら一時的に直ることがありますが、Authorization、Referer、独自ヘッダー、サーバー制限が原因なら直りません。対象サイトのCookieを消す前に、別ブラウザとの違いと大きい項目を確認してください。
WordPress本体のエラーですか？
WordPressへ届く前にCDN、WAF、Apache、Nginxが返すことがあります。WordPressのHTTPクライアントが外部APIから431を受け取るケースもあります。応答ヘッダーと各層のログで発行元を確認します。
431ではなく400と表示されることもありますか？
あります。実装は必ず431を使うとは限りません。Nginx公式資料では、一つの要求ヘッダーがバッファを超えると400になると説明されています。番号とエラーログを一緒に確認してください。
上限を増やす目安はありますか？
サイト共通の万能値はありません。正常な要求の実測、最も小さい中継層の制限、防御とメモリへの影響を確認し、必要な余裕だけを管理者が設定します。異常に大きい要求へ合わせてはいけません。
まとめ
431 Request Header Fields Too Largeは、要求ヘッダー全体または一項目が受信側の許容サイズを超えた状態です。WordPressではCookieが有力ですが、認証、Referer、独自ヘッダー、CDN・サーバー制限も分けて確認します。
- 入力を退避し、ログイン状態とブラウザ差を確認する
- 秘密値を見せず、肥大したヘッダー名を特定する
- Cookieや独自ヘッダーの生成元を一か所ずつ直す
- CDN・プロキシ・Webサーバーの発行元と上限を確認する
- 上限調整は、正常要求でも不足するときの最後の手段にする
Cookie削除で一度開けたことをゴールにせず、再び膨らむ生成元まで直すことが、安全で再発しにくい復旧につながります。