400 Bad Request: Request Header Or Cookie Too Large (nginx), fixed and tested

nginx shows this page when one request header line, almost always the Cookie line, is bigger than its buffer. We reproduced it with curl and with Chrome, then raised the limit.

1. What the error looks like

HTTP/1.1 400 Bad Request
Server: nginx/1.31.6
Content-Type: text/html
Content-Length: 233
Connection: close

<title>400 Request Header Or Cookie Too Large</title>
...<h1>400 Bad Request</h1>
Request Header Or Cookie Too Large

It comes from nginx itself, before your application runs, so your app logs show nothing.

2. What triggers it (default nginx, measured)

The default is large_client_header_buffers 4 8k, which sets two limits: each header line (name, value and line ending) must fit in one 8 KB buffer, and all headers together in four of them, about 32 KB. A browser sends all cookies on one Cookie line, so it is the cookies' combined size that hits the 8 KB per-line limit, long before the 32 KB total. Many small cookies fail just like one big one.

3. Same thing in Chrome

Chrome refuses to store any single cookie whose name plus value exceeds 4,096 bytes: a 4,096-byte cookie was kept, a 4,097-byte one was silently dropped, whether it came from Set-Cookie or document.cookie. So one cookie can't cause this error; several can. With 4,000-byte cookies on the same host:

The page stays broken on every visit, because the browser keeps sending the same cookies until they expire or are deleted.

4. Fix it as a visitor

Delete the cookies for that one site; you don't need to clear everything. In Chrome: click the icon left of the address bar → Cookies and site data → Manage on-device site data → delete the site's entries, then reload. Or open DevTools → Application → Storage → Clear site data. A private window works too, because it starts with no cookies. If the error returns soon after, the site itself keeps setting too many cookies and only its owner can fix that.

5. Fix it as the server owner

Raise the buffers in the http or server block and reload:

large_client_header_buffers 4 16k;   # each line up to 16 KB, about 64 KB in total
nginx -t && nginx -s reload

Measured with 4 16k: a Cookie line with 16,372 bytes of value (16,384-byte line) passed and 16,373 failed; a 15 KB Cookie line that failed before now passed; 64 header lines of 1,000 bytes passed and 65 failed; a 40 KB Cookie line still failed. The per-line limit is the second number, so raise that one for cookie problems; raising only the count doesn't help: with 8 8k, 64 lines of 1,000 bytes passed but an 8,193-byte Cookie line still failed.

Then find the cause, or the next deploy will hit the new limit. Typical culprits are analytics and A/B-testing cookies piling up on a shared parent domain, sessions stored entirely in a cookie, and big JWTs (check one with the JWT decoder). If a CDN or load balancer sits in front, it has its own limit too. Node.js answers 431 instead of 400; limits for both servers are in HTTP header size limits, measured.

6. Reproduce it

curl -i -H "Cookie: a=$(head -c 9000 /dev/zero | tr '\0' a)" https://your-site/

A 400 with the text above means nginx refuses lines of that size. Over HTTP/2 nginx applies the same directive to header fields, per its documentation.

Written with AI assistance. Measured on 2026-10-01 against nginx:alpine 1.31.6 (default config, then large_client_header_buffers 4 16k and 8 8k) with curl 8.14, and in Chromium 153: a Node server set 4,000-byte cookies on 127.0.0.1, then Chromium loaded the nginx page on the same host. Chrome's per-cookie limit was tested with both Set-Cookie and document.cookie. Deleting cookies was tested by clearing the browser's cookies; the Chrome menu names are from Chrome's settings UI, not automated. The 'http or server block' placement and the HTTP/2 note are from the nginx documentation, not this test. PlainHeaders is our extension; DevTools and curl show the same, free.