499 status code: what nginx means by client closed request

What the 499 status code means

499 Client Closed Request is nginx-specific and never defined in any RFC. Codes above 99 and below 600 are reserved for HTTP status lines in general, but 499 is nginx's own convention, logged when nginx detects that the client's connection dropped while it was still waiting for the upstream application to respond, or while it was still sending the response body back to the client. The most common real-world shape is a slow upstream combined with a client, browser tab, or load balancer whose own timeout is shorter than however long the server was going to take, so the client hangs up first.

How it appears in logs

You will never see 499 as a status code returned to any client, browser, curl, or otherwise, because by definition the client is already gone by the time nginx would have sent it. It exists only in nginx's own access log:

10.0.0.12 - - [19/Sep/2026:14:02:11 +0000] "GET /api/report HTTP/1.1" 499 0 "-" "python-requests/2.31"

The response size of 0 bytes and the timing relative to your upstream's known response time are the two most useful details: a 499 that consistently lands right around your upstream timeout, with nothing sent back, points squarely at "the backend was too slow and something gave up waiting."

What causes a 499

• A slow upstream application. The backend is taking longer to respond than some client or intermediary is willing to wait, whether that is a slow database query, an external API call, or a genuinely heavy computation.
• A client-side timeout shorter than the server needs. A browser tab closed, a mobile app giving up on a flaky connection, or an HTTP client library's own timeout firing before the response arrives.
• A load balancer or upstream proxy timing out first. If something sits between the actual end user and nginx, its own timeout can trigger a disconnect that nginx logs as 499, even though the real end user never explicitly cancelled anything.
• A user navigating away or refreshing. Someone clicking away from a slow-loading page, or hitting refresh impatiently, closes the in-flight connection before nginx was done.
• Timeout values that are inconsistent across the chain. A client, a CDN, a load balancer, and nginx itself can each have a different timeout, and whichever one is shortest determines when the disconnect happens, regardless of what the others are configured for.

Why it never appears in a browser

499 is not a response, it is a note nginx makes to itself about a response it never got to finish sending. A user whose tab produced a 499 in your logs sees nothing at all: no error page, no status code, just a page that stopped loading or a spinner that never resolved, because there was no response for the browser to render. This is exactly why relying on user-reported errors misses these entirely; the only place a 499 is visible is the server's own access log.

How to fix and reduce 499s

There is no single setting that eliminates 499s, since the underlying cause is a race between the client giving up and the server finishing, and the fix depends on which side of that race is actually broken. Start by establishing whether the upstream is consistently slow for the affected route, or whether the disconnects cluster around one client, network, or intermediary, since those point at different fixes.

1. Investigate the upstream response time first, since a slow backend is the most common underlying cause. Look at how long the affected requests actually took upstream, not just that nginx logged a 499.
2. Align timeout values across the whole chain, deliberately, rather than leaving each layer's default in place: client, CDN, load balancer, and nginx's own proxy_read_timeout and proxy_connect_timeout should be set with a clear understanding of which one is meant to fire first.
3. Consider proxy_ignore_client_abort if letting the upstream finish its work even after the client disconnects matters for your application, for example to complete a write that should not be left half-done:

   proxy_ignore_client_abort on;

   This does not prevent the 499 log entry for the original disconnect; it changes whether nginx keeps the upstream request running regardless.
4. Speed up the actual upstream work where the root cause is genuinely a slow endpoint, since no amount of timeout tuning fixes a backend that takes too long by itself; profile the specific slow queries or calls behind the affected route.
5. Treat a rising 499 rate as a real signal, not log noise to filter out, since it usually means either your application got slower or your timeout configuration is mismatched somewhere in the chain.

How to prevent it from becoming an outage

Because 499 never reaches the client as a visible error, it is easy for a genuinely slow endpoint to go unnoticed until someone reads the access logs, even while real users are quietly abandoning requests. A scheduled HTTP check measures actual response time against the endpoint directly and alerts when it degrades, catching the slowdown that is producing the 499s before it grows into requests failing outright. Monitoring from multiple locations also helps separate a genuinely slow backend from a timeout that only trips for clients on a particular network path.

Related errors

See 504 Gateway Timeout for the standard, client-visible equivalent when nginx itself gives up waiting on the upstream rather than the client giving up first, the 4xx overview for the standard client-error family, and 429 Too Many Requests for a different kind of rejection tied to rate rather than timing.

Frequently asked questions

Is 499 a real HTTP status code?

No. It is nginx's own logging convention for a client that disconnected before the response finished, and it is never sent over the wire to any client since the client is already gone by the time it would be sent.

Why does my monitoring tool never see a 499?

A monitoring check is itself a client, and if it is the one giving up on a slow response, it will report its own timeout error, not 499, since it never receives an HTTP response to read a status code from. 499 only ever appears in the server's own access log entry for that request.

Does a 499 mean my server crashed?

No. It specifically means the server was still working, or about to start working, when the client disconnected. A crash would typically produce a 502 or 500 instead, once something did respond.

Can I stop upstream processing when a client disconnects?

By default nginx will generally stop waiting on the upstream once the client is gone, but the exact behavior depends on your proxy settings; proxy_ignore_client_abort on tells nginx to let the upstream request continue rather than abandoning it.

What is the most common fix for frequent 499s?

Aligning timeout values across the client, any intermediate proxy or load balancer, and nginx itself, combined with addressing whatever is making the upstream slow in the first place. Neither alone usually resolves a persistent pattern.