問題描述：
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
注：只在做反向代理的時候加入，作爲其他服務器的時候，關閉爲好，默認設置是關閉的！