The browser shows 400, but my nginx log says 494. Which is it?

Both, and they're the same event seen from two sides. 494 is an nginx-internal status — NGX_HTTP_REQUEST_HEADER_TOO_LARGE — so it only appears in your access log ($status). It isn't a registered HTTP status code, so nginx can't put it on the wire; it sends the client a plain 400 Bad Request with the body 'Request Header Or Cookie Too Large.' The client sees 400; your log shows 494. It's the same trick nginx uses for 495 (bad client cert), 496 (no client cert), and 497 (plain HTTP on the HTTPS port).

How is 494 different from 431?

They describe the same problem — request headers that are too big — but 431 Request Header Fields Too Large is the registered HTTP code from RFC 6585, while 494 is nginx's private log code for the same condition. nginx doesn't emit 431; it logs 494 and returns 400. So if you're reading nginx access logs you'll see 494, and if you're reading the response in a browser or curl you'll see 400 with 'Request Header Or Cookie Too Large.' Some other stacks (Node, IIS) return an actual 431. Same class of bug, different label depending on who's talking.

Why does it clear when I use an incognito window?

Because incognito starts with no cookies, and cookies are the usual culprit. A single request header line has to fit inside one buffer. nginx reads the first headers into client_header_buffer_size (1 KB by default) and spills larger ones into large_client_header_buffers (four 8 KB buffers by default). One oversized Cookie header — session junk, tracking cookies, a stack of feature flags that never got cleaned up — blows past that and trips 494. Incognito has an empty cookie jar, so the request is small and sails through. That's your tell that the fix is on the client, not the server.

Views: 8

494 Request Header Too Large (nginx)

494 Request Header Too Large is nginx's log code for oversized headers, usually a bloated cookie. Isolate client vs server. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Your nginx access log records a request as status 494, and the person who made the request got a 400 Bad Request with the body text Request Header Or Cookie Too Large. Nothing is wrong with the server — nginx didn’t crash, the upstream never got the request, TLS was fine. nginx rejected the request before it did any real work because the request’s headers were bigger than the buffers set aside to hold them. Ninety percent of the time that means a cookie has quietly grown too fat. The question worth answering is whether every visitor is hitting this or just the ones carrying a specific bloated cookie, because that decides whether you touch the server config at all.

Symptoms

The client sees 400 Bad Request with the exact body Request Header Or Cookie Too Large; the nginx access log shows status 494.
It affects some users and not others — often the ones who’ve been on the site a while and accumulated cookies — while a fresh browser or incognito window loads fine.
Clearing that site’s cookies makes it disappear immediately, then it may creep back over days as the app rebuilds them.
It’s more likely on endpoints that carry big headers: pages behind SSO, apps with large JWTs in Authorization, or anything sitting behind a proxy that injects its own headers.

What This Error Actually Means

494 is one of nginx’s non-standard internal status codes, defined in its source right next to 495 (client certificate failed verification), 496 (client presented no certificate), and 497 (plain HTTP arrived on the HTTPS port). Internally it’s NGX_HTTP_REQUEST_HEADER_TOO_LARGE. Because 494 isn’t a registered HTTP status, nginx never sends it to the client — it returns a 400 Bad Request and logs 494 for you.

The mechanics are about buffers, not policy. nginx reads the request line and the first headers into a buffer sized by client_header_buffer_size, which defaults to 1 KB. When the headers don’t fit, nginx allocates from large_client_header_buffers, which defaults to four buffers of 8 KB each. There’s a rule people miss: a single header line — one name and its value — must fit inside one buffer. So four 8 KB buffers don’t give you a 32 KB budget for one Cookie header; they give you room for several headers that each fit in 8 KB. One Cookie line larger than a single buffer trips 494 no matter how many buffers you have. That’s why the fix is sometimes “make the buffer bigger” and sometimes “stop sending a giant cookie,” and telling those apart is the whole job.

Top 3 Causes

A cookie that grew too big - By far the most common. Session data, tracking pixels, A/B-test assignments, and feature flags pile into cookies over time, and browsers send all of them on every request to the domain. Eventually one Cookie header exceeds a single buffer and every request from that browser gets 494 until the cookies are cleared. If it’s one user’s browser and not the whole site, this is almost always it.
A large token or injected header - A fat JWT in Authorization, a long Referer, or headers added by a proxy, SSO gateway, or WAF in front of nginx. Each hop that appends context (X-Forwarded-*, auth claims, trace headers) makes the header block bigger, and the request can be well under the limit at the browser but over it by the time it reaches nginx.
Buffers left at the defaults for a header-heavy app - The 1 KB / 8 KB defaults are fine for a plain site and too small for one that legitimately carries big auth headers. If every user hits 494, not just the cookie-heavy ones, the server’s buffers are undersized for the traffic it’s actually serving.

Diagnose with DechoNet

HTTP Check requests the same URL from outside your network with a minimal, cookie-free set of headers. If DechoNet gets a normal 200 while a real browser gets 494/400, the server is fine and the oversized headers are coming from the client — clear that site’s cookies and the problem goes with them. If DechoNet also gets 400 Request Header Or Cookie Too Large, the server is rejecting even a small request, which points at buffers set too low or a proxy in front injecting headers. That one check tells you which side to fix before you touch a config file.

Resolution Checklist

Reproduce and scope it. Load the URL in a normal browser (fails) and an incognito window with no cookies (works). If incognito works, the fix is client-side; if incognito also fails, it’s server-side.
If it’s the client, clear that site’s cookies (or have the affected users do it). Then find what’s inflating them — an app that keeps appending to a cookie, a tracking script, or session data that belongs server-side — so it doesn’t grow back.
If it’s the server, raise the buffers in the http block: client_header_buffer_size 4k; and large_client_header_buffers 4 16k;. Set them at the http level so every server block inherits them, then reload nginx. Remember the single-line rule: if one header exceeds one buffer, increase the size (the 16k), not just the count.
If a proxy, load balancer, or SSO gateway sits in front, check what headers it adds. The request can be small at the browser and oversized at nginx because an intermediary appended auth or forwarding headers. Trim what it injects, or size nginx’s buffers for the real header total.
Don’t paper over it with an unlimited buffer. Very large header buffers are a memory and denial-of-service footgun. Fix the cookie or the injected header rather than granting 64 KB of header space to every connection.

When to Escalate

If clearing cookies fixes it but it returns within days, the application is rebuilding a bloated cookie. That’s an app change — move the data server-side or stop appending to the cookie — not an nginx setting.
If it only happens through your proxy or CDN and direct requests to the origin are clean, an intermediary is inflating the headers. Hand it to whoever owns that hop with the direct-vs-proxied evidence.
If every user hits 494 the moment they authenticate, the auth header (a JWT or SSO cookie) is legitimately larger than one buffer. Either shrink the token or size large_client_header_buffers for it — there’s nothing to “clear” on the client side.