🚨 NGINX Error Guide: '400 Request Header Or Cookie Too Large' — Fix Header Buffers

Overview

NGINX returns 400 Bad Request with the body text Request Header Or Cookie Too Large when a client’s request headers exceed the buffer NGINX reserves for them. The error log records it explicitly:

2026/07/09 13:15:02 [error] 1201#1201: *44120 client sent too long header line: "Cookie: session=...<many kilobytes>..." while reading client request headers, client: 203.0.113.77, server: app.example.com, request: "GET /dashboard HTTP/1.1", host: "app.example.com"

The trigger is header size, not request body size (that’s 413). The usual culprit is a bloated Cookie header — many cookies, or one huge one — but oversized Authorization: Bearer <JWT> tokens and long Referer/custom headers cause it too. NGINX limits header buffers deliberately to bound per-connection memory, so oversized headers are rejected rather than allowed to consume unbounded RAM.

Symptoms

• Clients get 400 Bad Request with Request Header Or Cookie Too Large in the response body.
• The error log shows client sent too long header line: followed by the offending header (often a giant Cookie).
• The failure is user-specific: users with many accumulated cookies or a large session fail while others succeed.
• Clearing cookies for the site makes the problem disappear temporarily, then it returns as cookies re-accumulate.
• It appears after adding SSO/JWT auth that puts a large token in a header or cookie.

Common Root Causes

• Bloated cookies — third-party scripts, feature flags, and analytics each setting cookies until the Cookie header exceeds the buffer.
• Large JWTs / SAML tokens — an Authorization header or auth cookie carrying a big signed token, sometimes with many claims.
• Default buffers too small for the app — large_client_header_buffers at its default 4 8k when the app legitimately needs more.
• Long request lines — enormous query strings can trip the same limit (the request line shares these buffers).
• A redirect loop that appends cookies — misconfigured auth that keeps stacking cookies on each hop.

Diagnostic Workflow

Confirm from the error log which header is oversized:

grep 'too long header line' /var/log/nginx/error.log | tail

Measure the actual header size a client is sending, so you can size buffers to reality rather than guessing:

# Reproduce with a deliberately large cookie and watch for the 400
curl -s -o /dev/null -w '%{http_code}\n' -H "Cookie: big=$(head -c 20000 /dev/zero | tr '\0' 'x')" https://app.example.com/dashboard

Raise the header buffers to comfortably fit legitimate headers. large_client_header_buffers number size — the size must exceed your biggest single header line:

http {
    # Default is "4 8k". Increase size (per-buffer) to fit big cookies/JWTs.
    large_client_header_buffers 4 32k;

    # These also bound header handling; keep them consistent
    client_header_buffer_size 4k;   # initial buffer for small headers
}

Validate and reload:

nginx -t && nginx -s reload

Then verify the previously failing request now succeeds:

curl -s -o /dev/null -w '%{http_code}\n' -H "Cookie: big=$(head -c 20000 /dev/zero | tr '\0' 'x')" https://app.example.com/dashboard

Example Root Cause Analysis

Users of an internal dashboard intermittently hit 400 Request Header Or Cookie Too Large, and the pattern was telling: long-tenured employees failed while new hires didn’t. The error log showed client sent too long header line: "Cookie: ..." — the offending header was a Cookie several kilobytes long. Over months, feature-flag cookies, A/B test assignments, and analytics identifiers had accumulated until the header exceeded the default large_client_header_buffers 4 8k (an 8k per-buffer limit).

The immediate fix was raising the buffer to large_client_header_buffers 4 32k, which restored access. But the team correctly treated that as a band-aid: the real problem was unbounded cookie growth. They audited cookie sources, moved several large client-side values into server-side session storage keyed by a small session id, and set expirations on the flag cookies. Header size dropped back to a few hundred bytes, well within even the original buffer — so the larger buffer became headroom rather than a necessity.

Prevention Best Practices

• Size large_client_header_buffers to fit your legitimate maximum header (JWTs, session cookies) with margin — but treat a large value as a symptom, not a solution.
• Keep cookies small: store large state server-side behind a small session id rather than in client cookies.
• Audit third-party scripts and feature-flag tooling for cookie bloat; expire and prune cookies you no longer need.
• If you use JWTs in cookies or headers, keep claims minimal; big tokens both trip this limit and slow every request.
• Set client_header_buffer_size and large_client_header_buffers consistently, and match any downstream proxy/load-balancer header limits so the request doesn’t just fail one hop later.
• Alert on too long header line in the error log so cookie creep is caught before users are locked out.

Quick Command Reference

# Find the oversized header
grep 'too long header line' /var/log/nginx/error.log | tail

# Reproduce with a large cookie
curl -s -o /dev/null -w '%{http_code}\n' \
  -H "Cookie: big=$(head -c 20000 /dev/zero | tr '\0' 'x')" https://HOST/PATH

# Current buffer setting
grep -rn 'large_client_header_buffers' /etc/nginx/

# Validate and reload after resizing
nginx -t && nginx -s reload

Conclusion

400 Request Header Or Cookie Too Large means the request’s headers — usually a bloated Cookie or a big Authorization JWT — exceeded NGINX’s large_client_header_buffers. Raising the buffer restores access immediately, but the durable fix is to shrink what clients send: move large state server-side, prune cookies, and keep tokens lean. Size buffers to your legitimate maximum with margin, match limits on downstream proxies, and treat rising header sizes as a warning sign rather than a reason to keep bumping the buffer.