HTTP 499 Client Closed Request: who gave up, and why

Most likely first.

1. The caller's timeout is shorter than the response time. The most common cause. A script with --max-time 10, a timeout=10 in Python or an AbortSignal.timeout() in JavaScript closes the connection when the time is up, and the server logs 499 for a request it was still working on.
2. A load balancer or CDN in front gave up first. When the layer in front of nginx has a shorter timeout than the application, it closes its connection to nginx and answers the visitor itself, usually with 504. nginx logs 499 and the visitor never sees that number.
3. A person left. Closing the tab, pressing stop, clicking a link before the page finished or submitting a form twice all cancel requests that were in flight.
4. The client cancels on purpose. Search boxes that cancel the previous request on each keystroke, clients that send the same request to two servers and drop the slower one, and health checks with a short deadline.
5. A proxy or its exit dropped in the middle. When a request travels through a proxy, the server sees the proxy's exit as the client. If the exit goes offline or the proxy closes the tunnel, the server logs 499 although the program that sent the request was still waiting.

1. 1Log how long each request ran

   $request_time is the time from the first bytes read from the client to the log write. $upstream_response_time is the time spent receiving the answer from the application. 499s whose request time piles up at a round number such as 10.000, 30.000 or 60.000 point to a timeout set by the caller or by a layer in front.

   nginx.confCopy

   log_format timed '$remote_addr [$time_local] "$request" $status $body_bytes_sent '
                    'rt=$request_time urt=$upstream_response_time "$http_user_agent"';
   access_log /var/log/nginx/access.log timed;

2. 2See which URLs are abandoned

   In the default combined log format the status is the ninth field and the path the seventh. A few slow URLs with most of the 499s are a speed problem; 499s spread evenly over every URL point to the network or to a layer in front.

   Most abandoned pathsCopy

   awk '$9 == 499 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

3. 3Check who the client is

   Look at the address in the log line. If it is your load balancer or your CDN, the visitor did not close the connection: that layer did, and its own log has the status the visitor received.

4. 4Reproduce it with a deadline

   Give curl less time than the URL needs. curl prints error 28 and status 000, and the server logs 499 for that request.

   Two seconds for a slow URLCopy

   curl -sS -o /dev/null --max-time 2 -w "%{http_code} %{time_total}s\n" https://TARGET/slow

• Answer faster, or answer early

  Speed up the slow URLs the log points to. For work that takes long by nature, accept the request, answer at once with a job ID and let the caller ask for the result.

• Line up the timeouts

  Each layer should wait a little longer than the one behind it: the application's own limit shortest, then nginx's proxy_read_timeout, then the load balancer or CDN, and the caller longest. Then a slow request ends as a clear 504 from your side, not as a closed connection.

• Let important work finish

  By default nginx closes its connection to the application when the client leaves. proxy_ignore_client_abort on keeps it open until the application answers. Use it for requests that must not be cut short, such as payments.

  nginx.confCopy

  location /payments/ {
      proxy_ignore_client_abort on;
      proxy_pass http://app;
  }

• Make repeats safe

  The application may finish the work after the caller has gone. In our test a server that took 10 seconds completed and wrote its answer without any error, 8 seconds after the caller had closed the connection. Before a client retries a request that changes something, give the request an idempotency key so the second attempt does not do the work twice.

• On the calling side

  Set a timeout that fits the slowest answer you expect, and retry requests that are safe to repeat with a growing pause. Through a proxy, allow for the longer route: a deadline that works on a direct connection can be too short through a residential exit.

• NGX_HTTP_CLIENT_CLOSED_REQUEST in ngx_http_request.h — nginx
• proxy_ignore_client_abort and proxy_read_timeout — nginx
• Log format and $request_time — nginx
• Error 499 — Cloudflare
• Troubleshoot your Application Load Balancers: HTTP 460 — AWS
• google.rpc.Code: CANCELLED maps to HTTP 499 — Google
• HTTP status code registry — IANA
• 408 Request Timeout and 504 Gateway Timeout (RFC 9110) — IETF / RFC Editor