Nginx 反向代理偶发 499，先分清是客户端断开还是后端超时

线上 Nginx 的 access log 里偶尔出现 499，很多人第一反应是“后端慢”，但 499 的定义是客户端在服务端返回响应之前就关掉了连接，它和后端超时是两件事，处理方向完全不同。

先说怎么区分。看三条信息：request_time、upstream_response_time、upstream_status。如果 request_time 很小（几十毫秒）且 upstream_response_time 也很小，说明后端早就返回了，是客户端自己跑了；如果 request_time 接近 upstream_response_time 且都很大，才是后端慢；如果 upstream_response_time 是 "-"，说明请求还没打到后端，客户端就断了。

实测中最常见的三种成因：

第一种，用户等不及刷新或关闭页面。移动端弱网下尤其明显，前端发起的请求没有 abort 逻辑，用户退出页面后连接被浏览器直接断掉，Nginx 就记一条 499。这类 499 不需要处理，但可以通过前端 AbortController 主动取消，减少无效请求。

第二种，后端响应头先发、body 迟迟不结束。有些框架开启了 gzip 流式输出但中间件缓冲了数据，客户端等不到第一个字节就超时断开。用 curl 加 --no-buffer 能复现，解决办法是关掉中间层的缓冲，或在 Nginx 上把 proxy_buffering 显式打开并设置合理的 buffer 大小。

第三种，连接被中间设备掐断。公司出口的防火墙、云厂商的 WAF 对长连接有空闲超时，超过就直接 RST。表现是固定时间点集中出现 499，比如整 60 秒、整 300 秒。对着时间点比对 keepalive_timeout 就能确认。

调优建议按这个顺序来：先把 client_header_timeout 和 client_body_timeout 设成和业务匹配的值，避免大文件上传被提前断开；再确认 proxy_ignore_client_abort 保持默认 off，不要为了让日志好看去打开它，否则后端白跑；最后在业务侧加幂等和重试，别让 499 变成脏数据。

一个容易忽略的点：499 上升时不要只看 Nginx，把 upstream 侧的连接数和队列长度一起看。如果是后端连接池耗尽，请求在 upstream 排队，客户端等不到响应而断开，日志同样会记 499，但根因在连接池配置，改 Nginx 一点用都没有。