共计 3648 个字符，预计需要花费 10 分钟才能阅读完成。
问题描述：
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)”
问题分析：
1 499 出现的原因
google 定义：
499 / ClientClosed Request
An Nginx HTTP server extension. This codeis introduced to log the case when the connection is closed by client whileHTTP server is processing its request, making server unable to send the HTTP header back
维基百科定义：
499Client Closed Request (Nginx)
Used in Nginx logs to indicate when the connection has been closed by client while the server is still processing itsrequest, making server unable to send a status code back
Nginx 源码：
grep 一下 nginx 源码，定义在 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 中赋值
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）server 处理请求未结束，而 client 提前关闭了连接，此时也会返回 499。
（3）在一个 upstream 出错，执行 next_upstream 时也会判断连接是否可用，不可用则返回 499。
总之，这个错误的比例升高可能表明服务器 upstream 处理过慢，导致用户提前关闭连接。而正常情况下有一个小比例是正常的。
继续分析：
问题的核心就是要排查为什么服务端处理时间过长
可能问题：
1 后台 python 程序处理请求时间过长
2 mysql 慢查询
通过查看监控：
1 cpu 和内存的使用，都在正常范围
2 后台程序访问正常
3 MySQL 没有慢查询
结果：
经过询问老大后得知，这个 nginx 为查询违章的 api，用户提交查询后，python 就去数据库或者交通局的网站查询。这个查询会有消耗一定的时间，所以，用户会主动断开连接
解决问题：
proxy_ignore_client_abort on; #让代理服务端不要主动关闭客户端的连接。
默认 proxy_ignore_client_abort 是关闭的，此时在请求过程中如果客户端端主动关闭请求或者客户端网络断掉，那么 Nginx 会记录 499，同时 request_time 是「后端已经处理」的时间，而 upstream_response_time 为“-“(已验证)。
如果使用了 proxy_ignore_client_abort on ;
那么客户端主动断掉连接之后，Nginx 会等待后端处理完 (或者超时)，然后记录「后端的返回信息」到日志。所以，如果后端返回 200，就记录 200；如果后端放回 5XX，那么就记录 5XX。
如果超时 (默认 60s，可以用 proxy_read_timeout 设置)，Nginx 会主动断开连接，记录 504
注：只在做反向代理的时候加入，作为其他服务器的时候，关闭为好，默认设置是关闭的！
CentOS 7.2 下编译安装 PHP7.0.10+MySQL5.7.14+Nginx1.10.1 http://www.linuxidc.com/Linux/2016-09/134804.htm
搭建基于 Linux6.3+Nginx1.2+PHP5+MySQL5.5 的 Web 服务器全过程 http://www.linuxidc.com/Linux/2013-09/89692.htm
CentOS 6.3 下 Nginx 性能调优 http://www.linuxidc.com/Linux/2013-09/89656.htm
CentOS 6.3 下配置 Nginx 加载 ngx_pagespeed 模块 http://www.linuxidc.com/Linux/2013-09/89657.htm
CentOS 6.4 安装配置 Nginx+Pcre+php-fpm http://www.linuxidc.com/Linux/2013-08/88984.htm
Nginx 安装配置使用详细笔记 http://www.linuxidc.com/Linux/2014-07/104499.htm
Nginx 日志过滤 使用 ngx_log_if 不记录特定日志 http://www.linuxidc.com/Linux/2014-07/104686.htm
Nginx 的 500,502,504 错误解决方法 http://www.linuxidc.com/Linux/2015-03/115507.htm
CentOS 7 编译安装 Nginx1.10.2 脚本启动失败解决思路 http://www.linuxidc.com/Linux/2017-01/139794.htm
Nginx 的详细介绍 ：请点这里
Nginx 的下载地址 ：请点这里
本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2017-01/140058.htm
