2026年8月10日

431 エラー（Request Header Fields Too Large）の原因と解決方法｜Cookie 削除で直る理由と Nginx・Apache の上限設定

エラー・白い画面

WordPressで「431 Request Header Fields Too Large」が表示される原因のほとんどは、ブラウザがサイトに送るCookieが増えすぎて、リクエストヘッダーがサーバーの上限を超えたことです。まずそのサイトのCookieを削除して表示が戻るかを確かめ、戻るならCookieを増やしている仕組みを止め、必要な場合に限ってサーバー側の上限を少し引き上げる、という順で対処します。この記事では、原因の切り分け、閲覧者側の応急処置、Cookieを増やしている原因の見つけ方、NginxとApacheでの上限の確認と変更までを順に説明します。

431エラーとはどういう状態か

HTTPステータス431は「リクエストヘッダーのフィールドが大きすぎるので処理しない」という意味の応答です。ブラウザはページを開くたびに、URL以外にもCookie、User-Agent、Refererなどをヘッダーとして送ります。このうち日々増えていくのはほぼCookieだけなので、431の調査はCookieから始めるのが近道です。

注意したいのは、同じ原因でもサーバーによって返すエラーが違う点です。

Nginx: 多くの場合、431ではなく「400 Bad Request（Request Header Or Cookie Too Large）」を返します
Apache: 「400 Bad Request」に「Size of a request header field exceeds server limit」といった説明が付きます
Node.js製の開発サーバーや一部のプロキシ・CDN: 431をそのまま返します

つまり、431という番号が出ている場合は、WordPressを動かしているWebサーバーではなく、その手前のCDNやプロキシ、あるいはローカル開発で使っているNode.js製のサーバーが返している可能性があります。どこで止まっているかによって直す場所が変わるため、次の切り分けが大切です。

まず切り分ける: 自分だけか、全員か

別のブラウザやシークレットウィンドウで開く

シークレットウィンドウ（プライベートブラウズ）は既存のCookieを送らないため、ここで正常に表示されるなら、原因は「そのブラウザに溜まったCookie」とほぼ判断できます。シークレットウィンドウでも431になる場合は、ログイン直後に大量のCookieが発行されている、URLのクエリが極端に長い、プロキシが独自のヘッダーを付け足している、といったサーバー側の要因を疑います。

Cookieのサイズを見る

ChromeやEdgeでは、開発者ツールの「Application」パネル（日本語表示では「アプリケーション」）の「Cookies」から、そのサイトのCookieを一覧で確認できます。サイズの列で並べ替えると、大きなCookieや、名前に連番やIDが付いた似たCookieが大量に並んでいないかが分かります。

「Network」パネルで失敗したリクエストを選び、リクエストヘッダーのCookie行の長さを見る方法もあります。コンソールで document.cookie.length を実行すると概算の文字数が分かりますが、HttpOnly属性付きのCookieは含まれないため、実際より小さく出る点に注意してください。

サーバーの上限をcurlで再現する

サーバー側の上限がどのくらいかは、大きなCookieを付けたリクエストを送ると確かめられます。

# 約9,000バイトのCookieを1つ付けて送る（既定の8KB前後の上限を超える大きさ）
curl -s -o /dev/null -w '%{http_code}\n' \
  -H "Cookie: test=$(head -c 9000 /dev/zero | tr '\0' 'a')" \
  https://example.com/

400や431が返れば、その経路のどこかに8KB前後の上限があると分かります。CDNを経由している場合は、オリジンサーバーに直接送った結果と比べると、どちらで止まっているかを判断できます。

閲覧者側の応急処置: そのサイトのCookieを削除する

自分のブラウザだけで起きているなら、そのサイトのCookieを削除すれば表示は戻ります。ブラウザ全体の履歴を消す必要はなく、開発者ツールのCookie一覧から対象のドメインを選んで削除するか、ブラウザの設定画面のサイトデータ管理から該当サイトだけを削除します。WordPressのログインCookieも消えるため、管理画面には再ログインが必要です。

同じ症状が繰り返し報告されるなら、サイト側がCookieを増やし続けている可能性が高いため、次の原因調査に進みます。

Cookieを増やしている原因を探す

WordPress本体が発行するCookie（ログイン状態を示す wordpress_logged_in_ で始まるもの、管理画面の表示設定を保存する wp-settings- で始まるものなど）は小さく、本体だけで上限を超えることはまずありません。原因になりやすいのは次のようなものです。

投稿ごと・商品ごとに別名のCookieを作るコード: 閲覧履歴やアクセスカウンター、ポップアップの表示済みフラグなどで、viewed_123、viewed_124 のようにIDを名前に入れると、閲覧するたびにCookieが1つずつ増えます
アクセス解析・広告・A/Bテストのタグ: 複数のサービスを入れていると、それぞれが識別用のCookieを発行します
サブドメイン間の共有Cookie: .example.com のように親ドメインに対して発行されたCookieは、shop.example.com や staging.example.com などすべてのサブドメインに送られます。同じドメインで複数のサイトを運用していると、合計が膨らみやすくなります
**ローカル開発環境の localhost**: 複数のプロジェクトを localhost で開発していると、別プロジェクトのCookieが同じホストに溜まります。Node.js製の開発サーバーやプロキシ経由で確認していて431が出る場合は、この可能性が高いです

Cookieの名前から発行元のプラグインやサービスを特定できたら、そのプラグインの設定でCookieの使用を止められないか、別の方法に置き換えられないかを検討します。プラグインの無効化で切り分ける場合は、事前にバックアップを取り、Cookieを削除したブラウザで1つずつ無効化して、Cookieの増え方が止まるかを確認します。

自作コードなら1つのCookieにまとめる

自分のテーマやプラグインで投稿ごとにCookieを発行しているなら、1つのCookieに件数の上限付きでまとめると、増え続ける問題を解消できます。次は「最近見た投稿」を最大10件だけ保持する例です。

<?php
// 最近見た投稿のIDを1つのCookieに最大10件まで保存する（PHP 7.3以降）
add_action( 'template_redirect', function () {
	if ( ! is_singular( 'post' ) ) {
		return;
	}

	$ids = array();
	if ( isset( $_COOKIE['recent_posts'] ) ) {
		$raw = sanitize_text_field( wp_unslash( $_COOKIE['recent_posts'] ) );
		$ids = array_map( 'absint', explode( ',', $raw ) );
	}

	array_unshift( $ids, get_queried_object_id() );
	$ids = array_slice( array_values( array_unique( array_filter( $ids ) ) ), 0, 10 );

	setcookie( 'recent_posts', implode( ',', $ids ), array(
		'expires'  => time() + 30 * DAY_IN_SECONDS,
		'path'     => COOKIEPATH,
		'domain'   => COOKIE_DOMAIN ? COOKIE_DOMAIN : '',
		'secure'   => is_ssl(),
		'httponly' => true,
		'samesite' => 'Lax',
	) );
} );

Cookieの値は利用者が自由に書き換えられるため、読み込むときは数値に変換して使います。また、ページキャッシュが有効なサイトではPHPが実行されずCookieが更新されないことがあるため、キャッシュの除外設定や、ブラウザ側のlocalStorageで保持する方法も合わせて検討してください。古い別名のCookieは自然には消えないので、修正後は有効期限を過去にしたCookieを発行して削除するか、閲覧者に削除を案内します。

サーバー側の上限を確認・変更する

Cookieを減らすのが本来の対策ですが、正規の利用でも上限に近い場合は、サーバーの上限を少し引き上げます。上限は大きすぎるリクエストでメモリを消費させる攻撃を防ぐ役割もあるため、むやみに大きくせず、既定値の2倍程度から試すのが無難です。設定ファイルは変更前に複製してバックアップを取ってください。

Nginxの場合

Nginxでは large_client_header_buffers で、長いヘッダー1行を受け取るバッファの数と大きさを決めます。既定値は 4 8k で、1つのヘッダー行（Cookie行を含む）が8KBを超えるとエラーになります（2026年10月現在）。

# /etc/nginx/nginx.conf の http ブロック内
http {
    client_header_buffer_size 1k;
    large_client_header_buffers 4 16k;
}

この2つは server ブロックにも書けますが、同じIPとポートで複数のサイトを動かしている場合、既定のサーバー（default server）の値が使われることがあります。意図どおりに効かないときは http ブロックに書いてください。HTTP/2でも、Nginx 1.19.7以降はこの large_client_header_buffers が上限として使われます。

変更後は構文を確認してから再読み込みします。

sudo nginx -t && sudo systemctl reload nginx

Apacheの場合

Apacheでは LimitRequestFieldSize が1つのヘッダーの上限で、既定値は8190バイトです。この設定はサーバー全体の設定ファイルかバーチャルホストの設定に書くもので、.htaccess には書けません。.htaccess に書くとエラーになるため注意してください。

# 例: /etc/apache2/apache2.conf や httpd.conf、または <VirtualHost> 内
LimitRequestFieldSize 16380

名前ベースのバーチャルホストでは、同じIPとポートで最初に定義されたバーチャルホストの値が使われる場合があります。変更後は sudo apachectl configtest で構文を確認し、sudo systemctl reload apache2（RHEL系では httpd）で反映します。

共有レンタルサーバーやCDNの場合

共有レンタルサーバーでは、これらの値を利用者が変更できないのが一般的です。CDNやWAFにも独自の上限があり、オリジン側を変えても手前で止まる場合があります。どちらの場合も、サーバーの設定変更ではなくCookieを減らす対策で解決するのが現実的です。

解決したかを確認する

対策後は、curlのコマンドで上限の変化を確かめ、Cookieを削除したブラウザでログインやフォーム送信などを一通り試して、Cookieの数とサイズが増え続けないかを開発者ツールで確認します。

まとめ

431の原因はほとんどがCookieの増えすぎ。シークレットウィンドウで表示できるかで、まず自分だけの問題かを切り分ける
NginxやApacheは同じ原因でも400を返すことが多く、431はCDNやプロキシ、Node.js製の開発サーバーが返している場合がある
閲覧者側の応急処置は、そのサイトのCookieだけを削除すること
投稿ごとに別名のCookieを作るコードや、サブドメイン間の共有Cookieを見直し、1つのCookieにまとめる
サーバーの上限はNginxの large_client_header_buffers、Apacheの LimitRequestFieldSize で、既定値の2倍程度から慎重に引き上げる