Nginx状态码499-错误分析

nginx日志大量499报错,分析与处理。

错误日志

220.181.165.136 - - [18/May/2015:10:31:02 +0800] "POST /v1/jobsHTTP/1.1" 499 0 "" "bdHttpRequest/1.0.0"

115.239.212.7 - - [18/May/2015:10:31:03 +0800] "GET /v1/job/643309e3-dc73-4025-aa69-c9405c1d818fHTTP/1.1" 499 0"http://www.baidu.com/?tn=91638679_hao_pg&s_j=1""Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko"
  
140.207.202.187 - - [18/May/2015:10:30:58 +0800] "POST/v3/violations HTTP/1.1" 499 0 "-" "-"

问题分析

499 CLIENT CLOSED REQUEST 
A non-standard status code introduced by nginx for the case when a client closes the connection while nginx is processing the request.

499  客户端关闭请求
Nginx在处理请求时，客户端关闭了连接，故nginx抛出了499这个状态代码。

大牛分析源码-摘录
/*
* HTTP does notdefine the code for the case when a client closed
* the connectionwhile we are processing its request so we introduce
* own code to logsuch situation when a client has closed the connection
* before we even tryto send the HTTP header to it
*/

意思是服务器在返回HTTP头之前，客户端就已经关闭了当前连接。很可能是因为服务器端处理的时间过长，客户端"不耐烦"了...

Nginx upstream在以下情况下会返回499状态码：

(1)upstream 在收到读写事件处理之前时，会检查连接是否可用，当连接错误时会返回499。
(2)server处理请求未结束，而client提前关闭了连接，此时也会返回499。

总之，这个错误的比例升高可能表明服务器upstream处理过慢，导致用户提前关闭连接。

为什么服务端处理时间过长？

可能的原因是：
(1)后台python程序处理请求时间过长
(2)mysql慢查询

尝试去验证结论：
(1)查看CPU和内存使用, 是否在正常范围
(2)后台程序访问是否正常
(3)验证mysql是否有慢查询

如果以上结论都正常，可以使用如下参数来优化

proxy_ignore_client_abort  on;  #让代理服务端不要主动关闭客户端的连接。

如果使用了 proxy_ignore_client_abort on ;

那么客户端主动断掉连接之后，Nginx 会等待后端处理完(或者超时)，然后记录「后端的返回信息」到日志。所以，如果后端返回200，就记录200 ；如果后端放回 5XX ，那么就记录 5XX.
如果超时(默认60s，可以用 proxy_read_timeout 设置)，Nginx会主动断开连接，记录504

注：建议只在做反向代理的时候使用。最好关闭这一选项。

参考: 51CTO

• 本文作者： GaryWu
• 本文链接： https://garywu520.github.io/2018/04/11/Nginx状态码499-错误分析/
• 版权声明： 本博客所有文章除特别声明外，均采用 MIT 许可协议。转载请注明出处！