Nginx 400 Request Header or Cookie Too Large: Fix the Cause, Not Just the Limit

The Nginx 400 request header or cookie too large error means the request headers exceeded the buffers Nginx reserved for them, and the usual culprit is one bloated or duplicated cookie.

Clearing cookies may make the page load again, but that only resets the symptom. The durable fix is to identify which header grew, decide whether the application or proxy created it, and increase Nginx limits only when the request is legitimately large.

Table of contents

• What the error actually means
• Confirm the cause before changing Nginx
• Use the smallest safe Nginx change
• Fix the application behavior that created it
• A production-safe recovery checklist
• How this fits the rest of the stack
• FAQ

What the error actually means

Nginx reads the request line and headers before it sends traffic upstream. If that header block does not fit into the configured buffers, Nginx rejects the request itself with a 400 response. Your application may never see it, so searching application logs alone can waste an afternoon. Cookies travel in the Cookie request header, which makes authentication sessions, analytics identifiers, experiments, and abandoned legacy values share the same limited space.

The useful distinction is scope. If one browser fails while a private window works, its stored cookies are probably oversized. If many users fail after a release, inspect new session or proxy behavior. A long request URI can also cause a related failure, but the log message and request shape help separate it from cookie growth.

Confirm the cause before changing Nginx

Reproduce the request with browser developer tools open and inspect the request headers. Compare a failing profile with a clean profile, then total the Cookie header and look for repeated names or unusually large encoded values. Check the Nginx error log at the same timestamp; messages about a client sending too large a header confirm the rejection happened at the edge.

sudo tail -f /var/log/nginx/error.log
curl -I https://example.com/
curl -v -H 'Cookie: session=test' https://example.com/

Also inspect every proxy in front of Nginx. A CDN, ingress, or load balancer may enforce a smaller ceiling, and changing only the origin will not alter that earlier rejection. Measure first because raising buffers blindly allocates more memory per connection and can conceal an application that stores far too much state in the browser.

Use the smallest safe Nginx change

For legitimate headers, tune the HTTP context or the specific server block and test the configuration before reloading. Keep the values proportional to observed traffic instead of copying a huge number from a forum. The first buffer handles ordinary headers; the larger buffers are used when a header or request line needs more room.

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

# Validate and reload
sudo nginx -t
sudo systemctl reload nginx

A 16 KB large buffer is an example, not a universal prescription. Confirm the compiled defaults and platform memory budget, then load-test the change. If an upstream proxy has its own limits, align them deliberately. A configuration that accepts a 60 KB cookie may remove the error while making every request slower and expanding an avoidable attack surface.

Fix the application behavior that created it

Session cookies should contain a compact identifier or a deliberately small signed payload, not an ever-growing user profile. Remove obsolete cookies with matching domain and path attributes, shorten retention where appropriate, and avoid issuing the same logical cookie from multiple subdomains. Authentication refresh loops are a common source of duplicates: each redirect writes another token until the browser sends a small novel back with every request.

Add header-size visibility at the edge without logging secrets. Record aggregate byte counts and the names of unusually large cookies, then alert on a rising percentile. Never dump raw session values into logs. The strongest fix is usually application state discipline; Nginx buffer changes should create reasonable headroom, not become the storage strategy.

A production-safe recovery checklist

1. Confirm a clean browser or cleared site cookies works
2. Match the failing request to an Nginx error-log entry
3. Measure the request header and identify the largest cookie names
4. Check CDN, ingress, and origin limits in request order
5. Remove the cookie growth bug before increasing buffers
6. Run nginx -t, reload gracefully, and test authenticated flows
7. Monitor header-size trends and 400 rates after release

For an immediate user workaround, clear cookies only for the affected site rather than wiping the entire browser. For the service fix, prefer expiring the bad cookie and deploying a bounded session format. That resolves existing broken clients and keeps new ones from reaching the same ceiling.

How this fits the rest of the stack

Request limits are part of capacity planning, not a magic knob. When the proxy, service, and bandwidth need to be costed together, the RunxBuild hosting calculator shows the line items before deployment, while the RunxBuild dashboard keeps routes and deploy logs in one operational view.

Useful related references:

• 504 Gateway Time-out in Nginx: Your Upstream Was Too Slow, Not Nginx
• Nginx Rate Limit: limit_req, limit_conn, and Burst
• Nginx Location Directive: Prefix, Regex, and Priority
• Response headers on RunxBuild

FAQ

Why does clearing cookies fix this Nginx 400 error?

It removes the oversized Cookie header, so the next request fits. The workaround does not fix the application behavior that created the large or duplicated cookie.

Where should large_client_header_buffers be configured?

Put it in the Nginx http or server context supported by your deployment, validate with nginx -t, and reload gracefully. Check any proxy in front of Nginx too.

Is increasing the buffer dangerous?

A modest measured increase can be reasonable, but very large buffers consume more memory and hide bad session design. Measure real headers and choose the smallest useful headroom.

Can a CDN still return the error after Nginx is changed?

Yes. The first proxy that rejects the header ends the request. Each CDN, load balancer, ingress, and origin can have a different limit.

Should cookies contain full user data?

Usually no. A compact session identifier is easier to revoke, keeps requests smaller, and avoids sending the same profile data on every asset and API request.