499 Client Closed Request
The client (a browser, app or load balancer) hung up before the server replied. Nobody sees a 499 page; it shows up in nginx logs.
Quick checks
- Find the 499s in the access log and note which URLs and how long they took ($request_time).
- Check whether the client is a load balancer or monitor with a short timeout.
If you’re visiting the site
You won't see this code
- A 499 is recorded after you left or your request timed out. If a page never loads, reload it or try later.
If you run the site
Find out who closes the connection
- Users pressing stop or navigating away cause a few 499s; that's normal.
- Many 499s at the same duration point to a client timeout, such as a load balancer, a CDN or an app's HTTP client.
Speed up the slow requests
- Profile the URLs with 499s: slow queries and external API calls are typical.
- Align timeouts: the proxy's upstream timeout should be shorter than the client's, so you get a clear 504 instead of a mystery 499.
Decide whether to keep processing
proxy_ignore_client_abort on;lets the upstream finish work (useful for writes) even if the client left.
Still not working?
A sudden spike of 499s usually means the backend got slower. Correlate with deploys, database load and upstream response times.
See what’s happening
For local development, LightAtom's connections view shows connections between your app and its backend opening and closing in real time.
Frequently asked questions
What does 499 mean in nginx?
Client Closed Request: nginx logs 499 when the client closes the connection before nginx sends the response. It's not an official HTTP status and is never sent to anyone.
Are 499 errors bad?
A few are normal: people close tabs. Many 499s mean requests are too slow and clients are timing out, so users are getting failures.
What is the difference between 499 and 504?
504 is sent by a gateway that stopped waiting for the upstream. 499 is logged when the client stopped waiting first.