499 Client Closed Request (tested)

499 Client Closed Request is an nginx log code. It means the client closed the connection before nginx sent a response. It is never sent to the client. We reproduced the same situation against a Node server to show what the backend sees and how to stop wasted work.

1. What 499 means

499 is not a real HTTP status. Only nginx uses it, and only in its access log. nginx writes it when the client disconnects while nginx is still waiting for the upstream or still working. No client ever receives a 499, because by then nobody is listening.

So a 499 is a timeout on the client side. The client got tired first. Compare 504 Gateway Timeout, where nginx gives up on the upstream, and 408 Request Timeout, where the server gives up on a slow client.

2. Our test setup

We have no nginx on the test box, so we measured the backend's view instead. A Node.js server ran a handler that does 5 s of work (50 ticks of 100 ms) and then sends 200. Four clients each gave up after 1 s. The server logged req and res 'close' events and res.writableFinished.

res.on('close', () => {
  if (!res.writableFinished) console.log('client aborted');
});

3. Results: every client abort looks the same to the server

In every case the server got res 'close' and req 'close' within about 10 ms of the client giving up. res.writableFinished was false every time. That is the Node equivalent of the 499 moment.

Without a check, the handler did all 5 s of work anyway. When it finally called res.end(), the socket was already destroyed (res.destroyed was true). The 200 it "would have sent" went nowhere. curl shows that clearly: the status is 000 and 0 bytes were received.

$ curl -sS -m 1 -w '%{http_code}\n' http://127.0.0.1:8983/slow
curl: (28) Operation timed out after 1000 milliseconds with 0 bytes received
000

4. Stop the wasted work

Turn the close event into an AbortSignal and check it in your work loop, or pass it to fetch and database calls that accept a signal.

http.createServer((req, res) => {
  const ac = new AbortController();
  res.on('close', () => {
    if (!res.writableFinished) ac.abort();   // client went away
  });
  doSlowWork({ signal: ac.signal })
    .then(body => res.end(body))
    .catch(err => { if (!ac.signal.aborted) throw err; });
});

With this guard, our curl test logged "work stopped after 9 ticks" 3 ms after the close. The Chromium fetch abort stopped at 9 ticks as well. That is about 0.9 s of work instead of 5 s.

Use res.on('close') with the writableFinished check. A plain req.on('close') also fires after a normal, finished response, so it alone does not prove an abort.

5. nginx specifics (from the docs, not measured)

When the client closes, nginx logs 499 and by default closes its connection to the upstream too. Your backend then sees the same close event we measured above.

proxy_ignore_client_abort on; tells nginx to keep the upstream request open after the client leaves. Use it for requests that must finish (for example a payment write). It does not help the client; the client is gone either way.

location /api/ {
    proxy_pass http://backend;
    proxy_read_timeout 60s;
    # proxy_ignore_client_abort on;  # only if the work must complete
}

6. Common causes

• Client or load balancer timeout shorter than the backend. A front load balancer, CDN or HTTP client gives up before nginx gets an answer. AWS ALB's default idle timeout is 60 s, so a request that takes longer is cut there.
• Users leave. They close the tab, click a link or hit stop. The browser aborts the request, as our Chromium test shows.
• Health checkers with short timeouts. A 2 s health check against a slow endpoint shows up as a steady stream of 499s.
• Frontend code that cancels requests. Type-ahead search and route changes often abort the previous fetch on purpose. Those 499s are harmless.

7. How to fix it

• Find who closed first. Compare $request_time in the nginx log with the client's timeout.
• Align timeouts so each layer waits a little longer than the one behind it: client > load balancer > nginx proxy_read_timeout > backend.
• Make slow endpoints fast or asynchronous. Return 202 with a job ID and let the client poll.
• Stop work on abort in the backend (section 4), so 499s do not pile up load.
• Point health checks at a cheap endpoint.

If you see resets rather than clean closes, read ERR_CONNECTION_RESET / ECONNRESET. If the upstream itself fails, see 502 Bad Gateway.

Written with AI assistance. Measured on 2026-10-02 with Node.js 24.21.0, curl 8.14.1, Python 3 urllib and headless Chromium 153 against a Node server whose handler takes 5 s. Each client gave up after 1 s. The nginx parts are from the nginx docs, not measured. PlainHeaders is our extension; curl, Python, Node.js and Chromium are free.