服务器排障 之 nginx 499 错误的解决

服务器排障之nginx499错误的解决

问题描述:

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 "-" "-"   42.236.10.71 - - [18/May/2015:10:30:59 +0800] "POST /v3/violationsHTTP/1.1" 499 0 "-" "-"   106.120.173.17 - - [18/May/2015:10:30:58 +0800] "POST/v3/violations HTTP/1.1" 499 0 "-" "Mozilla/5.0 (Windows NT6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.131Safari/537.36"   180.97.35.164 - - [18/May/2015:10:30:52 +0800] "GET/v1/job/f86bdecc-2a61-4a42-bb7b-aa794b77f89b HTTP/1.1" 499 0"http://www.baidu.com/s?word=%E5%8D%81%E5%A0%B0%E5%A4%A9%E6%B0%94&tn=sitehao123&ie=utf-8""Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)"

问题分析:

1499它出现的原因

谷歌定义:

499/客户端关闭请求

NginxHTTP服务器扩展。引入此代码是为了记录当HTTP服务器正在处理其请求时，客户端关闭连接，导致服务器无法发送回HTTP头的情况

维基百科定义:

499客户端关闭请求(Nginx)

在Nginx日志中使用，表示当服务器仍在处理其请求时，客户端已关闭连接，这使得服务器无法发回状态代码

Nginx源代码:

grepnginx源代码，在ngx_request_t.h中定义:

/* * 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 */ #define NGX_HTTP_CLIENT_CLOSED_REQUEST 499

这是nginx定义的一个状态码，用来指示在服务器返回http头之前，客户端提前关闭http连接的错误。

说吧，grep:

这很可能是因为服务器端处理时间太长，客户端“不耐烦”。

为了解决这个问题，我们需要在程序上做一些优化。

然后在grep中点击“NGX_HTTP_CLIENT_CLOSED_REQUEST”，发现当前状态值只在ngx_upstream中赋值。

在下列情况下，上游将返回499:

（1）upstream 在收到读写事件处理之前时，会检查连接是否可用： ngx_http_upstream_check_broken_connection，     if (c->error) { //connecttion错误 　　　　 ……         if (!u->cacheable) { //upstream的cacheable为false，这个值跟http_cache模块的设置有关。指示内容是否缓存。             ngx_http_upstream_finalize_request(r, u, NGX_HTTP_CLIENT_CLOSED_REQUEST);         } }

如上，连接错误时将返回499。

(2)2)服务器处理请求没有完成，客户端提前关闭连接，同样会返回499。

(3)如果上游发生错误，执行next_upstream时会判断连接是否可用，如果不可用则返回499。

总之，这个错误比例的增加可能说明服务器上游进程太慢，导致用户提前关闭连接。一般情况下，少部分是正常的。

继续分析:

问题的核心是找出服务器处理时间过长的原因。

可能的问题:

1后台python程序处理请求的时间太长。

2mysql慢速查询

通过查看进行监控:

1cpu和内存使用都在正常范围内。

2后台程序访问正常。

3MySQL没有慢查询

结果:

问了老板才知道，这个nginx是一个查询违规的api。用户提交查询后，python会去数据库或者交通局网站查询。这个查询需要一定的时间，所以用户会主动断开连接。

解决问题:

proxy_ignore_client_aborton；#让代理服务器不主动关闭客户端的连接。

默认情况下，Proxy_ignore_client_abort是关闭的。此时，如果请求过程中客户端主动关闭请求或者客户端网络断开，Nginx会记录499，request_time是后端已经处理的时间，而upstream_response_time是“-”(已验证)。

如果使用了proxy_ignore_client_aborton

然后在客户端主动断开连接后，Nginx会等待后端完成处理(或者超时)，然后在日志中记录“后端信息”。所以后端返回200，就记录200；如果后端放回5XX，则记录5XX。

如果超时(默认为60s，可以通过proxy_read_timeout设置)，Nginx会主动断开连接并记录504。

注意:只在做反向代理时加入。作为其他服务器，还是关掉比较好。默认设置是关！