nginx 400 Request Header Or Cookie Too Large: How to Fix It

nginx returns this page when the request line or one header field from the browser does not fit into the buffers it allocates for headers. In practice the culprit is almost always the Cookie header, which grows every time a site, plugin or tracking script adds another cookie to the same domain.

The page reads "400 Bad Request - Request Header Or Cookie Too Large" with nginx at the bottom. A visitor sees it on one site only, often only in one browser, and it vanishes in a private window. See the HTTP 400 reference for the generic status.

How nginx decides a header is too large

Two directives control this, both valid in http and server contexts:

• client_header_buffer_size defaults to 1k. Every request first gets a buffer this size.
• large_client_header_buffers defaults to 4 8k. If the request line or a header field does not fit in the first buffer, nginx allocates up to 4 buffers of 8 KB each.

A single header field must fit in one large buffer. If a request line is longer than one buffer, nginx returns 414. If one header field is longer than one buffer, it returns 400. So with defaults, a Cookie header larger than about 8 KB is rejected, no matter how much total space is left.

The error log entry is usually this:

client sent too long header line: "Cookie: session=eyJ0eXAiOiJKV1Qi..."

The related message client sent too long URI appears when the request line overflows instead, and the response is 414. nginx logs these at the info level, so you will not see them unless the error_log directive is set to info, for example error_log /var/log/nginx/error.log info;.

Fix for visitors

1. Delete cookies for that site only. In Chrome open the padlock icon, choose Cookies and site data, and remove the entries for the domain. Reload.
2. Test in a private window to confirm cookies are the cause.
3. If the problem returns within days, tell the site owner, because something on the site is writing too much cookie data.

Fix for site owners, in this order

1. Find what is bloating the cookie

Measure the header size on a failing request. In browser developer tools, open the Network tab, click the request and look at the request headers. Or reproduce it with curl:

curl -s -o /dev/null -w "%{http_code}\n" \
  -H "Cookie: $(python3 -c 'print("a=" + "x"*9000)')" https://example.com/

A 400 here confirms that your buffer limit is about 8 KB. Inspect real cookies with the Cookie Checker and look at what your application sets.

Typical sources of oversized cookies:

• Many analytics, A/B testing and ad scripts writing separate cookies on the parent domain, which then travel to every subdomain.
• Sessions stored entirely in the cookie, such as a large JWT or serialized framework session.
• Cookies that are set on .example.com by an old subdomain and never expire.
• A redirect or login loop that appends data to a cookie on every request.

Fixing the source is better than raising the limit, because large cookies also slow every request, including ones for images and CSS.

2. Raise the buffers if the size is legitimate

If you really need large headers (for example big SSO tokens), raise the limit in http or in the relevant server block:

http {
    client_header_buffer_size 4k;
    large_client_header_buffers 4 16k;
}

Test and apply:

sudo nginx -t && sudo systemctl reload nginx

Buffers are allocated on demand and released when the connection goes into keep-alive, so moderate increases are cheap. Avoid huge values such as large_client_header_buffers 8 1m, which makes it easier for abusive clients to consume memory.

3. Check proxies and upstreams as well

The request must also pass every layer behind nginx. If nginx proxies to Apache, Apache has its own LimitRequestFieldSize (default 8190 bytes) and LimitRequestLine. Node.js servers have a maximum header size as well. Application servers such as Tomcat, Gunicorn and uWSGI each have equivalent limits. If you raise nginx and the error continues, find out which component answers. The response body and Server header usually identify it. Use the HTTP Header Checker from the outside.

A CDN or load balancer in front of nginx can also reject large headers with its own error before nginx sees the request.

Where the config lives

• Debian and Ubuntu: /etc/nginx/nginx.conf and /etc/nginx/sites-enabled/, with logs in /var/log/nginx/error.log.
• RHEL, Rocky, Alma, Fedora: /etc/nginx/nginx.conf and /etc/nginx/conf.d/*.conf, logs in /var/log/nginx/error.log.

Dump the full effective config with sudo nginx -T and search for the directives: sudo nginx -T | grep -n header_buffer.

Confirm the fix

Replay the large-cookie request that failed. It should now return the normal status code instead of 400. Then check the error log (at info level) for new too long header messages and make sure the real pages still respond using the HTTP Status Checker. Add the affected page to an Uptime Monitor so a regression does not go unnoticed.

Next steps

• Inspect the cookies a site sets with the Cookie Checker.
• Read cookie flags: Secure, HttpOnly, SameSite.
• If requests now pass but time out, see nginx upstream timed out.
• Compare behavior with Apache in Apache vs nginx troubleshooting.

FAQ

Is this a browser problem or a server problem?

Both. The browser stores and sends too much cookie data, and the server refuses to accept it. Clearing cookies fixes the visitor's case, while the owner should remove the cause or raise the limit.

What is a safe value for large_client_header_buffers?

For most sites 4 16k is plenty. Increase it only after you have measured the header sizes you actually receive.

Why does it only happen on some subdomains?

Cookies set on the parent domain are sent to every subdomain, so a subdomain with an already large cookie jar can hit the limit while another does not.

Does this error mean my site is down?

Not for everyone. Only requests with oversized headers fail, so a normal uptime check passes. A visitor-specific check with a realistic cookie set is needed to catch it.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.