背景

        499作为nginx自定义的状态码，不像400、401、500、502等常见的http状态码，很多不太常用nginx的人可能并不能清楚理解他的含义，本文将简单介绍一下499状态码的含义，以及出现后的排查和处理思路，以及proxy_ignore_client_abort参数是否能有效。

499是什么

        nginx 对499的定义是  client has closed connection。这个定义比较模糊，简单来说就是nginx在完成响应之前客户端断开了连接。

499是如何产生的

        根据上面的定义，499产生的核心原因是客户端在nginx完成响应之前断开了连接。可以不太严谨的概括就是nginx完成的响应时间超过了客户端的超时时间。

排查思路

        上面对499产生原因的概括其实不太准确，实际上造成499的原因有很多，接下来我就介绍主要的排查思路，以及我平时比较常见的几种情况。

        nginx作为火了很多年的高性能web服务，有许多的应用场景，我选择比较常见的反向代理服务场景来介绍一下

在上述架构下，客户端发起一个请求大约要经历下面这些阶段

        这只是一个比较简单的流程，实际上会更复杂一些，比如中间可能还是一些网络设备已经其他的基础服组件。

499的触发时机

        由于499是nginx记录的状态码，所以客户端断开连接的时机是要在nginx接收HTTP请求行，到nginx发送响应这个区间内，所以如果客户端在DNS解析或者TCP建连之前就超时的话是不会触发499的，毕竟请求都没有到达nginx。如果nginx已经开始返回响应了，此时客户端就断开连接的话，不会记录499，会以响应的状态码为准，比如200。

499的影响

        上面说过，499代表客户端超时断开了连接，大部分情况下499代表请求失败了，需要根据业务场景评估影响。比如如果客户端有重试逻辑， 499之后重试成功，那么实际上可能不会有很大的影响。

        499还有一个比较容易被忽视的影响，由于499代表客户端断开了连接，那么客户端重试的时候意味着会重新建立tcp连接甚至重新tls握手，在一些高并发的场景下，大量的499导致的客户端重试可能会对服务端造成一定的压力，此时我们需要考虑在服务端做一些降级策略，减少499造成的重试压力。

499的排查方向

        我们之前提到过，499触发的根本原因是nginx返回的响应时间超过了客户端的超时时间，所以我们一般有下面几个排查方向：

1. 后端响应时间是否过长

        这里的后端是一个比较笼统的说法，实际的后端逻辑中可能还包含数据库的访问以及api的调用等，我们可以先通过查看nginx 499的访问日志中的upstream_response_time 字段确认后端处理时间是否明显增加，如果是的话可以再进一步定位异常的环节。

2. nginx处理时间是否过长

       需要查看nginx服务器的负载，比如cpu idle，load，网卡流量，io等是否有明细的升高或不足， nginx一般作为统一的反向代理服务，会代理多个域名，可以通过分析nginx请求日志，查看499的是否具有普遍性，如果在不同的域名，不同的后端服务中均有大量出现。配合之前说的nginx负载问题再进一步深入定位。

3. 客户端超时时间是否过短

        这种情况需要看下nginx的499的request_time是否都比较短，且几乎相等，需要去看客户端代码中的调用的超时时间是否设置的不合理。

        对相应时间要求比较高的服务比较容易出现499，由于http协议的限制，客户端想提前终止请求必须关闭连接，所以比较容易出现499。

4. 客户端网络质量是否太差

        这种情况服务端很难确认，需要有客户端的访问日志或者使用一些拨测工具。

        以上是一些比较简单的定位思路，没涉及到一些性能问题的排查方向，这个涉及到服务、网络和操作系统等很多方向的内容，这里不展开详谈了。

        此外网上还有个传言是快速post的请求会导致触发nginx 499 。但是这个说法我从未找到具体的代码支持和复现，并且nginx是以性能著称的web服务，感觉不会有这种限制，个人倾向是以讹传讹。

如何解决

        通过上面的排查思路的介绍，我们其实可以发现产生499的原因有很多，核心解决思路就是增加客户端的超时时间，加快后端的响应速度，提供一些边缘加速服务优化客户端的访问链路等等。但是499终究是一个客户端行为，我们在服务端侧是很难完全解决的，根据业务场景的不同，可以自行评估499的重要程度，一般的业务场景少量偶发的499不需要特别关注。

proxy_ignore_client_abort 有用吗？

        然后就是简单聊一下 nginx的   proxy_ignore_client_abort 这个参数。nginx官方的解释是：

Determines whether the connection with a proxied server should be closed when a client closes the connection without waiting for a response.proxy_ignore_client_aborthttp://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_ignore_client_abort

        nginx默认会在client关闭连接的时候，同时关闭nginx向上游服务（后端）的连接，这个参数开启后，nginx将不会同步关闭后端服务连接，后端服务完成响应后，此次请求nginx也将不会记录499状态码，而是记录后端对应的响应状态码。

        不知道从什么时候这个参数被传为可以是“解决”499的方法，然后如果你阅读了我上面写的内容后，应该会明白，这个参数不是解决499而是忽略499。并且一般我是不建议开启此参数的。主要有这几个原因：

1. 修改了响应的状态码，掩盖异常请求

        开启这个参数后nginx的请求日志便和客户端的记录不一致。比如如果客户端已经超时，但是nignx这边仍然记录的一条200状态码的访问日志，这种后续问题排查和定位的时候，可能会提高排查难度。并且掩盖了499这一异常状态码，不利于及时发现异常。

2. ​​​​​​会浪费后端资源

        客户端发起了一些很重的请求超时后，可能会不断重试，开启此参数nginx则不会中断之前向后端发起的请求，可能会导致加重对后端资源的使用。

        所以proxy_ignore_client_abort并不是解决499的方法，大家一定要注意。

总结

        499是由于nginx响应完成前客户端就断开了连接导致的，排查原因一般从客户端网络状态，超时时间以及服务端的响应时间来排查。常见的业务场景下，少量的499其实不需要过多的关注。

        proxy_ignore_client_abort可以忽略499，但不是解决方法，不建议大家开启。没有证据能证明快速post导致nginx499，这个应该是谣传。