Nginx 400: "Request Header or Cookie Too Large" — Buffer Tuning Done Right

A request header (usually a bloated cookie or a huge token) exceeded large_client_header_buffers (or the 4k cookie line). Raise buffers for the affected server, and clean the cookie — the real disease is usually an ever-growing session blob.

What you'll see

Root causes

Cookie growth beyond the default buffer

Every subdomain and tracker adds cookies; the Cookie header crosses large_client_header_buffers (default 8k total across 4 buffers; the first line limited to default large buffer). One page load can send kilobytes of accumulated cookies.

Auth/proxy architectures with big headers

OIDC/JWT proxies (oauth2, forward-auth patterns) pass tokens via headers: a 12KB JWT overflows default client header limits designed for normal browser traffic.

Fix it

  1. Reproduce with the oversized header visible
    curl -v -H 'Cookie: sid=<realistic-blob>' https://host/   # or DevTools: copy the actual Cookie header from the failing session
  2. Raise the buffers for that server (not globally forever)
    # large_client_header_buffers 4 32k;   # and for proxy flows: proxy_buffer_size 32k; proxy_buffers 8 32k;
  3. Attack the cookie bloat itself
    # set SameSite/Domain correctly, delete stale analytics cookies, keep JWTs out of cookies where possible (or store a session id instead)
  4. JSON Web tokens: prefer the standard 431 response and sane limits
    # error_page 431 = @toobig;   # a clearer client-facing signal than a bare 400 with an HTML error page

Field note

414 (URI too long) vs 400 (header too large): both come from the same buffer family — 414 is the request line, 400 the headers. The tuning directive is the same one. Every increase in header buffers is per-connection memory: scope raises to the server blocks that need them (SSO/proxy vhosts), not the global http{} block for all sites.

Common questions

Why does the site work for some users and not others?

Cookie size varies per session: logged-in, long-lived, multi-subdomain sessions accumulate more. The failing users aren't broken — their (legitimately larger) headers crossed your threshold.

What sizes are safe?

large_client_header_buffers 4 32k handles JWT-heavy intranet flows; 16k covers most cookie bloat. Anything larger usually signals a data-design problem (storing payloads in cookies) worth fixing first.

Related fixes

Ship it right the first time

Our most-documented failures, packaged as ready-to-ship starter kits: Docker, Kubernetes, and Terraform.

Browse the template store →

One-time. Yours to modify. Instant download from the NinjaOps template store.