一、问题现象

监控发现Nginx服务日志中出现较多的499状态码，499状态码在Nginx中代表的是客户端在服务端返回之前主动断开了连接，由于客户端设置的超时时间为2s，故到达2s未收到服务端响应客户端主动断开了连接造成了499响应码。

二、可能的故障点

服务器的问题，例如CPU使用率高，队列堵塞，导致无法及时处理请求，从而导致客户端超时断开连接网络出现问题，丢包或者出现网络堵塞专线线路存在问题后端服务存在性能瓶颈，当流量变大时，响应时间提高，导致客户端超时断开连接三、排查服务器问题

使用top命令，查看CPU使用率低于10%，内存使用率低于20%，没有明显的性能波动。使用vmstat 1 20命令，发现CPU队列为1，服务器具备4个CPU，使用率较低，未有明显异常，io情况也正常。初步判断与服务器无关。

三、排查网络问题

使用ethtool eth0命令查看网络带宽配置情况，发现 Speed: 1000Mb/s，Duplex:Full，千兆的网卡全部打满，没有进行带宽限制。使用sar -n DEV 1 20命令查看网络的实时流量，可以看到rxkB/s峰值1800多，txkB/s峰值2400多，远远未达到网络上的流量限制，通过sar -n EDEV 1 20查看有网络错误的流量，发现均为0使用抓包工具在网络出口上进行抓包，发现网络数据包均正常发送，未有明显延时的情况初步判断网络设备没有问题。

四、排查专线线路问题

后端服务是合作方的服务，通过专线相连接，专线有主、备两条，分别属于电信和移动运营商，主线经过电信的排查带宽无问题，排查期间将线路切换到备线，问题依旧存在。

初步判断与专线线路无关。

五、排查后端服务性能问题

由于超过2s客户端主动断开了连接，无法判断后端服务是否收到了请求且是否正常响应。在nginx location模块的配置中添加配置： proxy_ignore_client_abort on;，添加此配置以后，虽然客户端到达2s以后会主动断开连接，但是nginx会继续转发到后端服务且等待后端服务返回，并打印日志。

添加完此配置以后，发现日志中已经没有出现499的响应码，查看response time大于2s的请求，发现均正常返回，但是响应时间超过2s，高峰之时，响应时间最高超过10s。

由此可以判断，后端服务是能够正常收到请求的，只是由于后端服务网络设备或者是后端服务在大流量的情况下性能不足，导致响应缓慢，从而出现大量499响应码。

六、排查结果

当流量升高时，大约1000TPS左右，响应时间显著提高，从原来毫秒级别变成最大超过10秒钟，此时使用ping发现没有网络延时，可以确定是后端服务存在性能问题。

以上排查主要是提供的排查的方法，逐步排查各个可能的故障点，实际生产排查中一般根据经验调整排查的顺序，例如直接就先排查后端的服务的响应时间，这个就依赖于个人的经验了。