nginx http 499错误码详解以及解决办法
作者：不喝咖啡会困死星人
背景
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_abort：http://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，这个应该是谣传。
到此这篇关于nginx http 499错误码详解以及解决办法的文章就介绍到这了,更多相关nginx http 499错误内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！