突然「400 Bad Request」や「request header or cookie too large」と表示され、特定のサイトだけ開けなくなると、原因が分からず焦ってしまいがちです。とはいえ、このエラーは多くの場合、ブラウザに保存されたCookieやリクエストヘッダーが大きくなり、サーバー側の上限を超えてしまうことで起きます。つまり、手順さえ分かっていれば、全Cookie削除のような大きな操作をせずに復旧できる可能性が高いのが特徴です。
本記事では、まず「対象サイトのCookieだけ削除する」という影響の小さい方法から、シークレットでの切り分け、拡張機能・別ブラウザ・別端末の確認まで、最短で直すための順番を丁寧に解説いたします。さらに運用者向けに、nginxやIngress-Nginx、IIS/http.sysなど環境別の再発防止ポイントも整理し、「直ったけれどまた起きる」を減らすための考え方までまとめます。今すぐサイトを開ける状態に戻したい方も、同様の問い合わせを減らしたい運用者の方も、まずは最初の手順から順番にお試しください。
※本コンテンツは「記事制作ポリシー」に基づき、正確かつ信頼性の高い情報提供を心がけております。万が一、内容に誤りや誤解を招く表現がございましたら、お手数ですが「お問い合わせ」よりご一報ください。速やかに確認・修正いたします。
request header or cookie too largeとは何が起きているのか
表示される代表的なエラーパターン
「request header or cookie too large」は、多くの場合「400 Bad Request」とセットで表示され、画面上には次のような文言が出ます。
400 Bad Request
Request Header Or Cookie Too Large
nginx（末尾に付くことがある）
The size of the request header is too long（類似表現）
ここで重要なのは、「サイトが落ちた」というよりあなたのブラウザが送ろうとしている“リクエスト情報”が大きすぎて、サーバーが受け付けられないという意味合いだという点です。Webアクセスでは、ブラウザはURLだけでなく、Cookieや各種ヘッダー（User-Agent、言語、圧縮方式、認証情報、追跡防止設定など）をまとめてサーバーへ送ります。そのうちのどれか、あるいは複数が膨らむと、サーバーや中継機器（CDN、WAF、ロードバランサー等）が定めた上限を超えてしまい、結果として400系のエラーが返されます。
特にこのエラーは「特定のサイトだけ開けない」形で起きやすいのが特徴です。なぜなら、Cookieはサイトごと（正確にはドメインやパスごと）に保存されるため、問題が起きているサイトに紐づくCookieが肥大化しているケースが多いからです。逆に言えば、影響を最小限に抑えながら直しやすいエラーでもあります。
なお、同じ端末でも「通常ウィンドウでは開けないが、シークレットでは開ける」ことがあります。これはシークレットモードが、通常とは別のCookie領域で動作し、拡張機能の影響も限定されるためです。つまり、シークレットで開けるなら「端末や回線の問題」よりも「通常モード側に蓄積されたCookieや拡張機能」が疑わしくなります。
Cookieとリクエストヘッダーが大きくなる主な理由
原因は大きく分けて「ユーザー側で膨らむもの」と「サイト運用側の仕組みで増えやすいもの」があります。代表例を押さえておくと、再発したときに切り分けが速くなります。
1. Cookieが増えすぎる（量・サイズの増加）
Cookieは基本的に「サイトがあなたを識別する」「設定を保持する」「ログイン状態を維持する」などの目的で使われます。ただし、次のような状況が重なると、Cookieの数や値の長さが増えていきます。
ログインやセッション管理が複雑で、Cookieの発行数が多い
使い終わったCookieが適切に削除されず、古いCookieが残り続ける
A/Bテストやパーソナライズが増え、識別用の値が追加され続ける
サブドメインごとにCookieが重複しやすい設計になっている
2. 認証・SSO・セキュリティ機構でヘッダーが重くなる
企業向けサービスでは、SSO（シングルサインオン）やセキュリティ製品の導入により、認証情報や検査情報がヘッダーへ付加されることがあります。Cookie以外のヘッダーが原因になることもあるため、「Cookieを消しても直らない」場合に視野に入れる価値があります。
3. ブラウザ拡張機能が余計なヘッダーを付与する
広告ブロッカー、セキュリティ拡張、翻訳拡張、開発者ツール系、プロキシ系などが、通信に追加情報を載せるケースがあります。特に会社支給PCで多層のセキュリティが入っている場合は、拡張機能というより組織のエージェント・プロキシの影響もあり得ます。
4. 中継機器（CDN/WAF/ロードバランサー）の制限
サイト運営側がオリジンサーバーを調整しても、CDNやWAFが先に弾く構成だとエラーが続きます。利用者側からは見分けにくいですが、「どの端末でも同じ」「友人も同じ」といった状況では、サイト側の制限が疑わしくなります。
request header or cookie too largeを最短で直す手順
対象サイトのCookieだけ削除する
最初に試すべきは「対象サイトのCookieだけ削除する」方法です。いきなり「すべてのCookieを削除」すると、他のサイトのログイン状態まで消えてしまい、復旧コストが跳ね上がります。ここでは、あくまで問題のサイトだけに絞って影響を小さくします。
実際に行う際のコツは、「削除範囲をドメイン単位で狙う」ことです。例えば example.com で問題が起きているなら、example.com と、そのサブドメイン（www.example.com、app.example.com など）に紐づくデータを対象にします。サイトによっては、ログインが accounts.example.com のように別サブドメインで完結しているため、1つ消しただけでは直らないことがあります。
対象サイトだけCookie削除をする前に、次を確認しておくと安全です。
再ログインに必要な情報（ID、パスワード、2段階認証手段）が手元にある
仕事用サービスなら、社内手順（情シス・管理者）に従う必要がないか
決済や予約の途中であれば、入力中の内容が失われる可能性を理解している
Cookieを削除すると、多くの場合「ログイン状態」が解除されます。これは不具合ではなく仕様です。削除後はページを開き直し、必要なら再ログインしてください。ここでエラーが解消されれば、原因はほぼ「そのサイトに紐づくCookieの肥大化・破損」と言えます。
キャッシュ削除とシークレットで切り分ける
対象サイトのCookieだけ削除しても改善しない場合、次は「シークレット（プライベート）ウィンドウ」と「キャッシュ」で切り分けます。順番は次の通りが効率的です。
シークレットで同じURLを開く
シークレットで開ける：通常モードに残っているCookie、キャッシュ、拡張機能などが疑わしい
シークレットでも開けない：サーバー側制限、ネットワーク、CDN/WAF、アカウント状態なども疑う
キャッシュの影響を除外する
キャッシュは本来、画像やスクリプトなどの再利用で高速化する仕組みですが、サイトデータや保存状態と絡み、表示や遷移が不安定になることがあります。対象サイト単位で消せる設定がある場合は、全体削除よりも先にそれを選びます。
ここで重要なのは、闇雲に「全部消す」を先にしないことです。原因がCookieであればCookie削除で足りますし、拡張機能が原因ならCookieを消しても再発します。シークレットを“診断モード”として使うと、次の一手が迷いません。
拡張機能・別ブラウザ・別端末で原因を分ける
それでも改善しない場合は、「その端末のそのブラウザ」に固有の問題かどうかを切り分けます。ここまで来ると、原因は次のいずれかに寄ります。
拡張機能やセキュリティツールが通信を増やしている
ブラウザのプロファイルが破損している（設定・データの不整合）
ネットワークやプロキシがヘッダーを追加している
サイト側が上限に達している（利用者側ではどうにもならない）
試す順序のおすすめは次の通りです。
拡張機能を一時的に無効化（特に通信に関与しそうなものから）
別ブラウザで同じURLを試す（Chrome→Edge/Firefox、Safari→Chromeなど）
別端末で試す（スマホ、別PC）
別ネットワークで試す（会社Wi-Fi→モバイル回線、家庭回線→テザリング）
ここで「別端末・別回線では開ける」なら、サイト側よりも利用者環境が疑わしいです。反対に「誰がやっても同じ」なら、サイト側の制限や障害の可能性が高まります。その場合は、運営の障害情報や問い合わせ窓口を確認した方が早いこともあります。
ブラウザ別にrequest header or cookie too largeを解消する方法
Chrome
Chromeでは「サイトデータ」から対象ドメインのCookieを削除できます。重要なのは「すべて削除」ではなく、まず対象サイトのみを狙うことです。
対象サイトだけ削除する基本手順（目安）
Chromeの設定を開く
プライバシーとセキュリティへ進む
Cookieと他のサイトデータ（またはサイトデータ）へ進む
サイトデータ一覧で対象ドメインを検索
対象ドメインのデータを削除
エラーの出るページを再読み込み（必要なら再ログイン）
うまくいかないときのポイント
サブドメイン（
app.やaccounts.）も同時に削除対象に含める直後に同じエラーが出るなら、拡張機能を一時停止して再試行
シークレットで開けるか確認し、通常モード固有かを確定する
Chromeは拡張機能が豊富である分、原因が拡張機能にあるケースも一定数あります。Cookie削除で改善しない場合は、拡張機能の一時停止が効果的です。
Edge
Edgeも基本構造はChromeと近く、Cookie削除の考え方も同じです。ただし、会社支給PCでは「企業ポリシー」や「組織の管理」により、削除や設定変更が制限される場合があります。
対象サイトだけ削除する基本手順（目安）
Edgeの設定を開く
Cookieとサイトのアクセス許可へ進む
Cookieとサイトデータの管理と削除へ進む
すべてのCookieとサイトデータ（一覧）を開く
対象ドメインを検索して削除
再読み込み（必要なら再ログイン）
会社PCでの注意点
企業プロキシやセキュリティゲートウェイがヘッダーを追加している場合、個人の操作では直らないことがあります
その場合は「別回線（スマホ回線）では開けるか」を確認し、ネットワーク起因を切り分けるのが早道です
Firefox
Firefoxは「Cookieとサイトデータ」管理が比較的わかりやすく、対象サイトの削除もしやすいです。
対象サイトだけ削除する基本手順（目安）
設定を開く
プライバシーとセキュリティへ進む
Cookieとサイトデータの「データを管理」を開く
対象ドメインで検索し、該当データを削除
再読み込み（必要なら再ログイン）
Firefoxでの切り分けポイント
アドオン（拡張機能）を一時停止して改善するか
強化型トラッキング防止の設定を変えた直後に起きていないか
サイトごとの例外設定がないか（Cookieブロック関連）
Firefoxでシークレット（プライベートブラウジング）を使った診断も有効です。通常モードでのみ発生するなら、保存データの影響が濃厚です。
Safari（iPhone/iPad含む）
Safariは、iPhone/iPadでは「設定アプリ」側からWebサイトデータを消す点が特徴です。全削除は影響が大きいため、可能なら対象サイト単位を優先します。
iPhone/iPadでの手順（目安）
設定アプリを開く
Safariへ進む
詳細 → Webサイトデータ（または履歴とWebサイトデータ）へ進む
対象ドメインのデータを削除
Safariに戻って再読み込み（必要なら再ログイン）
Safariで注意したい点
iOSのバージョンや表示項目の差で、対象サイト単位の削除が見つけづらいことがあります
全削除しか分からない場合でも、先に「シークレット」で開けるか確認してから判断すると、余計な影響を避けられます
運用者向けにrequest header or cookie too largeを再発防止する
nginxのヘッダー上限とlarge_client_header_buffers
運用者視点でこのエラーに対応する場合、「ユーザーにCookieを消してもらう」だけでは再発が続きがちです。なぜなら、根本原因が「アプリのCookie設計」や「アクセス経路上の上限設定」にあることが多いからです。
nginx環境で典型的なのは、リクエストヘッダーを受け取るためのバッファ上限に達しているケースです。Cookieはリクエストヘッダーの一部として送られるため、Cookieが大きくなるとこの制限に引っかかりやすくなります。
運用としての優先順位は次の通りが安全です。
発生状況の把握
いつから増えたか（デプロイ、設定変更、計測追加のタイミング）
どのURL・どの機能で多いか（ログイン、管理画面、特定APIなど）
特定ユーザーに偏っていないか（同一アカウントで再現するか）
どこで400が返っているかの確認
CDN/WAFが返しているのか
nginxが返しているのか
さらに下流（アプリ）が返しているのか
これを間違えると、調整しても改善しません。
アプリ側のCookie肥大化要因の棚卸し
使い終わったCookieの削除が適切か
期限、path、domainの設計で不要なCookieが残っていないか
A/Bテストや追跡用Cookieが増え続ける構造になっていないか
必要に応じてnginx設定の見直し
受け入れ上限を適切に調整する
ただし、無制限に上げるとメモリ使用量や攻撃耐性に影響が出るため、原因を把握したうえで最小限の変更に留めます。
設定で一時的に救済しつつ、アプリ側のCookie運用を改善する二段構えが、結果として最も安定します。
Kubernetes Ingress-Nginxでの調整ポイント
Kubernetes環境では、Ingress-Nginxが入口になっていることが多く、ここでもヘッダーサイズに関わる制限が問題になります。構成が複雑なほど「どこで弾かれているか」を誤認しやすいので、次の手順で整理すると事故が減ります。
Ingressのログとアプリログの両方を見る
Ingressで400になっているのか、アプリまで到達してから400なのかで対策が変わります。経路全体を洗い出す
例：クライアント → CDN → WAF → Ingress → Service → Pod
途中のどこかで上限が低いと、Ingressを調整しても意味がありません。変更点がCookie増加につながっていないか確認する
認証方式変更、A/Bテスト導入、計測タグ追加などは典型的な引き金です。
また、Ingress-Nginxは設定項目や推奨が更新されることがあります。過去の手順をそのまま当て込むのではなく、使用しているバージョンと推奨設定を前提に、チーム内の運用ルールを揃えておくと再発時に早く動けます。
IIS/http.sysの上限と調整（MaxFieldLength/MaxRequestBytes）
Windowsサーバー（IIS）系でも、要求ヘッダーが長い場合に400が返ることがあります。IISというより、背後のhttp.sysの制限が関係し、調整にはレジストリ変更が絡む場合があります。
運用上の注意点は明確です。
影響範囲が広い：サーバー全体に影響する可能性がある
再起動が必要なことがある：業務影響の調整が必要
セキュリティ面の配慮：上限緩和は攻撃耐性にも関わるため、根拠と検証が必須
したがって、IIS側の上限調整は「最後の手段」になりがちです。先に、アプリ側でCookieやヘッダーを肥大化させていないか、CDN/WAFに制限がないかを確認し、どうしても必要な範囲だけ調整します。
request header or cookie too largeが繰り返すときの原因と予防
ログインやトラッキングでCookieが肥大化する典型例
一度直っても、しばらくするとまた発生する場合、Cookieが「構造的に増え続ける」状況が疑われます。典型例を整理します。
ログインのたびにCookieが増える
本来は置き換えられるべきCookieが、新規追加され続ける。期限やpathの指定ミスで古いCookieが残るケースもあります。サブドメインをまたいでCookieが多重に付く
www、app、accountsなど複数ドメインが絡むと、利用者のCookie領域が膨らみやすくなります。計測・広告・A/BテストのCookieが蓄積する
テストが増えるほどCookieが増え、しかも値が長くなることがあります。組織のセキュリティやプロキシが付加情報を増やす
特定の会社ネットワークでのみ発生する場合、この可能性が高まります。
ユーザー側の予防としては、「対象サイトのCookie整理」「拡張機能の見直し」「別ネットワークで再現するかの確認」が現実的です。一方で、根本解決は運用者側（Cookie設計と上限設計）に寄ることが多い点は押さえておくとよいでしょう。
アプリ側でCookieに詰め込みすぎない設計の考え方
再発防止の観点では「Cookieに何を持たせるか」が核心になります。Cookieは便利ですが、“増やしやすい”わりに“上限に弱い”という性質があり、設計が雑だとすぐに限界にぶつかります。
考え方の基本は次の通りです。
Cookieは最小限の識別子に絞る
例：セッションIDや短いトークンのみにし、詳細情報はサーバー側ストアへ置く。不要Cookieの削除を確実に行う
テストや一時機能のCookieは、終了時に確実に削除されるようにする。期限切れだけに頼らない。path/domain設計を見直す
意図せず複数パス・複数サブドメインへ同一Cookieが広がると、リクエストごとに送られる量が増えます。デバッグ用途のCookieが残っていないか点検する
開発時に入れたフラグや冗長な値が本番に残ると、ユーザー全体へ影響します。
加えて、認証方式や追跡方式の変更はCookie増加につながりやすいので、変更時に「Cookieサイズ・ヘッダーサイズ」を監視指標に入れておくと、増加の兆候を早めに掴めます。
安全に消すためのチェックリスト
最後に、利用者がCookie削除を安全に進めるためのチェックリストをまとめます。特に仕事中の復旧では、焦って全削除してしまい、別サービスにも影響が出て混乱しがちです。
対象サイトのみのCookie削除になっている
サブドメイン（
accounts.など）も必要に応じて削除対象に入れた再ログイン手段（ID/パスワード/2段階認証）が手元にある
決済・予約・重要な入力途中ではない（途中なら一旦中断した）
シークレットで開けるかを確認し、原因切り分けができている
直らない場合に備え、別ブラウザ・別端末・別回線での検証手順が分かる
会社端末の場合、ポリシー上問題がないか確認した（不明なら情シスへ相談）
このチェックリストに沿って進めれば、影響を最小化しつつ復旧できる確率が上がります。
request header or cookie too largeのよくある質問
Cookieを消すと何が消える？
多くの場合、次がリセットされます。
ログイン状態（再ログインが必要）
サイトの設定（言語、表示設定、同意設定など）
一時的なセッション情報
一方で、対象サイトだけ削除していれば、基本的に他サイトへの影響は出ません。全Cookie削除は広範囲でログインが外れるため、最終手段として扱うのが安全です。
特定サイトだけ起きるのはなぜ？
Cookieはサイトごとに保存されるため、問題のサイトに紐づくCookieやヘッダーが肥大化していると、そのサイトだけでエラーが出ます。また、サイト側（CDN/WAF/サーバー）の上限が他より厳しい場合も、特定サイトだけで発生します。まずは「対象サイトのCookieのみ削除」と「シークレットでの再現」を行うと、原因の方向性が見えます。
運用者が先に確認すべきログ・監視指標は？
運用者が初動で確認すると効果が高いのは次の観点です。
400の増加開始時刻と直前変更（デプロイ、タグ追加、認証変更）
発生URLや機能の偏り（ログイン、特定APIなど）
CDN/WAF/Ingress/nginx/IISのどこでレスポンスが返っているか
特定ユーザー・特定ブラウザに偏っていないか
リクエストヘッダーサイズやCookieサイズの分布（可能なら計測）
「どこで弾かれているか」を誤ると、設定変更が空振りします。経路を意識した切り分けが重要です。
Cloud/CDN配下でも同じ対処でよい？
利用者側の対処（対象サイトCookie削除、シークレット、拡張機能切り分け）は基本的に同じです。
ただし運用者側は、CDNやWAFにもヘッダー制限があるため、オリジンだけ調整しても直らないことがあります。経路全体（CDN→WAF→LB→Ingress→Webサーバー→アプリ）で、どこが上限に達しているかを確認し、最も効果のあるポイントから対処するのが近道です。