sfw/fix
400 Header Too Large medium

400 Bad Request: Request Header Or Cookie Too Large

Nginx rejected the request because the cookies and headers the browser sent are bigger than its header buffers.

What you see

400 Bad Request
Request Header Or Cookie Too Large
nginx

What’s actually happening

One user gets a stark white Nginx 400 page on every page of a site while everyone else loads it fine, and an incognito window works immediately. It usually hits people who've been using the site for a long time, or sites that set a lot of cookies (analytics, A/B tools, several auth tokens). The request never reaches your app — Nginx rejects it at the header-parsing stage, so there's nothing in the application log.

Common causes

  • Accumulated cookies for the domain exceeding large_client_header_buffers (default 4 8k — i.e. 4 buffers of 8KB each).
  • A single oversized cookie, often a bloated session, a JWT stuffed with claims, or an SSO/identity cookie that keeps growing.
  • Many subdomains each dropping cookies on the parent domain, so every request carries the whole pile.
  • A redirect loop between an app and an identity provider that appends a cookie on each bounce until the header overflows.
  • Tracking/marketing scripts setting dozens of first-party cookies that all get sent back on every request.

How to fix it

  1. Clear cookies for that one site to unblock the user nowIn Chrome: lock icon > Cookies and site data > Manage > delete the site's entries, or DevTools > Application > Storage > Clear site data. This is the fastest client-side fix and confirms the diagnosis — if the 400 disappears, it was cookie bloat.
  2. Raise the header buffers in NginxIn the http or server block set 'large_client_header_buffers 4 16k;' (and bump 'client_header_buffer_size 16k;' if needed), then 'nginx -t && systemctl reload nginx'. Doubling to 16k clears almost all real-world cases. Don't go absurdly high — a 1MB buffer just hides a runaway cookie.
  3. Find what's writing the giant cookieOpen DevTools > Application > Cookies and sort by size. Anything over a few KB is suspect. A fat JWT usually means you're cramming data into the token that belongs server-side — move it to a session store keyed by a short ID.
  4. Scope or shrink the offending cookiesSet narrow Path/Domain attributes so cookies aren't broadcast to every subdomain, drop tracking cookies you don't read server-side, and put session state behind a small reference cookie instead of inlining it.

Stop it recurring

Keep total cookie size per domain well under 8KB and audit cookies after adding any auth, analytics, or A/B tool.

Related errors