はじめに

Web サイトで条件検索を繰り返していると、次のエラーが出ることがあります。

Bad Request
Your browser sent a request that this server could not understand.
Size of a request header field exceeds server limit.

この記事では、このエラーの一般的な意味を整理したうえで、実際によくある原因の1つである Cookie 肥大化を中心に解説します。

特に、条件検索を Cookie に保存している Web サービスで、検索条件の重複や追記によって 400 Bad Request になるケースを扱います。

実際に、条件検索を何度も繰り返したあとに 400 Bad Request が出て、Cookie を削除すると復旧する事象に遭遇しました。調べると、検索条件が Cookie に追記され続け、同じ値が重複して膨らんでいました。

先に結論

Size of a request header field exceeds server limit は、HTTP リクエストヘッダのどれか 1 つ、またはヘッダ全体がサーバーの上限を超えたときに発生します。

原因は Cookie だけではありません。よくある候補は次のとおりです。

Cookie の肥大化
Authorization ヘッダの肥大化
巨大な JWT
異常に長い Referer
カスタムヘッダの肥大化

そのうえで、実務では Cookie が原因のことがよくあります。
特に、条件検索のあるサービスで Cookie に検索条件を溜め込む実装だと起きやすい傾向があります。

このエラーで何が上限を超えているのか

HTTP リクエストには、次のようなヘッダが付きます。

Cookie
Authorization
User-Agent
Referer
そのほか各種カスタムヘッダ

今回のメッセージは request header field とあるため、URL 本体よりヘッダ側が主因です。

ただし、実際にどのヘッダが上限に達したかは、画面上のエラーメッセージだけでは断定できません。
そのため、まずはブラウザの開発者ツールやサーバーログで、どのヘッダが大きいのかを確認する必要があります。

今回扱うのは Cookie 肥大化の事例

この記事で扱うのは、条件検索画面で Cookie が肥大化するケースです。

例えば次のような流れで発生します。

検索条件を Cookie に保存している
条件変更のたびに Cookie が追記される
同じキーの重複値が増える
Cookie ヘッダが肥大化する
サーバー上限を超えて 400 Bad Request になる

画面上は「検索しているだけ」でも、内部では Cookie 文字列が毎回送られています。
そのため、利用者が気づかないままヘッダだけが大きくなります。

どういう Cookie だと膨らみやすいか

検索条件は次のように増えやすいです。

路線
駅
市区町村
家賃範囲
間取り
こだわり条件

さらに、次の実装だと急激に膨らみます。

条件更新時に上書きではなく追記している
配列を重複排除せず保存している
「前回条件」と「今回条件」を別キーで残している

例えば、次のような Cookie 文字列です。

Cookie: city_id=570; city_id=570; city_id=570; station_id=657; station_id=657; layout=2LDK; layout=2LDK

本来は 1 回だけ保持すればよい値が重複し続けると、Cookie サイズはすぐ増えます。

Cookie Size: 3KB
Cookie Size: 6KB
Cookie Size: 10KB
400 Bad Request

このように、ある境界を超えたところで突然失敗するのが厄介です。
実際にどの程度で上限に達するかは、サーバー構成や経路上のコンポーネントによって異なります。

利用者側ですぐできる対処

まずは該当ドメインの Cookie を削除します。

多くのブラウザでの手順は次のとおりです。

サイトを開いた状態で開発者ツールを開く
Application または Storage を開く
Cookies から該当ドメインを選ぶ
Cookie を削除して再読み込みする

短期対処としてはこれで復旧します。
ただし、サイト側の実装が同じなら再発します。

開発者が最初にやる切り分け

このエラーを見たら、最初から Cookie だけに絞り込まない方が安全です。

次の順で確認すると切り分けしやすいです。

ブラウザ開発者ツールで Request Headers を確認する
Cookie Authorization Referer など大きいヘッダがないか確認する
Cookie 削除後に同じ操作で再発するか確認する
サーバーアクセスログで 400 発生時刻と URI を突き合わせる
アプリの Cookie 書き込み処理で追記実装になっていないか確認する

Cookie 削除で改善するなら、Cookie 肥大化の可能性はかなり高いです。

サーバーごとに上限は違う

実務では、どこで弾かれているかも重要です。

上限は次のように構成要素ごとに異なります。

Nginx
Apache
ALB
CloudFront
アプリサーバ

例えば、Nginx では large_client_header_buffers、Apache では LimitRequestFieldSize の影響を受けます。

そのため、同じリクエストでも環境によっては通ることもあれば、別の環境では 400 Bad Request になることがあります。

ただし、設定だけを上げて解決したことにするのは危険です。
根本原因が Cookie の保存設計や更新ロジックにあるなら、いずれ再発します。

サービス提供側で検討したい恒久対策

ポイントは、検索条件を Cookie に積みすぎないことです。

1. Cookie には最小情報だけ保存する

Cookie には、次のような最小情報だけを入れます。

セッション ID
CSRF トークン
必須の表示設定

検索条件そのものは、サーバー側セッションや DB、または短命なストレージで管理する方が安全です。

2. 条件更新は常に上書きにする

同じキーを配列追記で増やさず、毎回次の処理を行います。

正規化
重複排除
上書き保存

この順にすると、同値の膨張を止められます。

3. URL と Cookie の責務を分ける

次の分担にすると運用しやすくなります。

共有したい検索条件: URL クエリ
一時的な状態: サーバー側セッション
永続プリファレンス: 必要最小限の Cookie

共有可能な検索条件を URL に寄せると、デバッグや問い合わせ対応もしやすくなります。

4. 受信前にサイズ監視を入れる

アプリに到達する前段で、ヘッダサイズを計測して可視化します。

平常時の Cookie サイズ分布
上限に近いリクエストの件数
ドメイン別、画面別の偏り

これを入れると、400 が大量発生する前に異常を検知できます。

サーバー設定変更は最後に考える

Nginx や Apache のヘッダ上限を上げると、一時的に改善することがあります。
ただし、これは恒久対策ではなく緩和策です。

実務では次の順を推奨します。

まず大きくなっているヘッダを特定する
Cookie 肥大化なら保存設計と更新ロジックを直す
そのうえで必要ならヘッダ上限を調整する
サイズ監視で再発を検知できる状態にする

まとめ

Size of a request header field exceeds server limit は、Cookie だけでなく複数のヘッダ要因で発生します。

そのうえで、条件検索のあるサイトでは Cookie 肥大化が比較的よくある原因です。

対処の要点は次のとおりです。

まずは該当ドメインの Cookie 削除で復旧を試す
開発者は Cookie 以外の巨大ヘッダも含めて切り分ける
検索条件を Cookie に蓄積しすぎない
条件更新は重複排除して上書きする
URL、サーバーセッション、Cookie の責務を分ける
必要ならサーバー上限を調整するが、先に根本原因を直す

この整理で、同種の 400 Bad Request はかなり減らせます。