問題描述：
Nginx 服務(wù)器大量499報(bào)錯(cuò)

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出現(xiàn)的原因
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定義的一個(gè)狀態(tài)碼，用于表示這樣的錯(cuò)誤：服務(wù)器返回http頭之前，客戶端就提前關(guān)閉了http連接
繼續(xù)grep :
wKioL1ZK_oWDZn9NAAC_HrhuQAs422.png

這很有可能是因?yàn)榉?wù)器端處理的時(shí)間過長(zhǎng)，客戶端“不耐煩”了。
要解決此問題，就需要在程序上面做些優(yōu)化了。

再grep下“NGX_HTTP_CLIENT_CLOSED_REQUEST”，發(fā)現(xiàn)目前這個(gè)狀態(tài)值只在ngx_upstream中賦值

upstream在以下幾種情況下會(huì)返回499：

（1）upstream 在收到讀寫事件處理之前時(shí)，會(huì)檢查連接是否可用： ngx_http_upstream_check_broken_connection，if (c->error) { //connecttion錯(cuò)誤……if (!u->cacheable) { //upstream的cacheable為false，這個(gè)值跟http_cache模塊的設(shè)置有關(guān)。指示內(nèi)容是否緩存。ngx_http_upstream_finalize_request(r, u, NGX_HTTP_CLIENT_CLOSED_REQUEST);} }

如上代碼，當(dāng)連接錯(cuò)誤時(shí)會(huì)返回499。
（2）server處理請(qǐng)求未結(jié)束，而client提前關(guān)閉了連接，此時(shí)也會(huì)返回499。
（3）在一個(gè)upstream出錯(cuò)，執(zhí)行next_upstream時(shí)也會(huì)判斷連接是否可用，不可用則返回499。
總之，這個(gè)錯(cuò)誤的比例升高可能表明服務(wù)器upstream處理過慢，導(dǎo)致用戶提前關(guān)閉連接。而正常情況下有一個(gè)小比例是正常的。
繼續(xù)分析：
問題的核心就是要排查為什么服務(wù)端處理時(shí)間過長(zhǎng)
可能問題：
1 后臺(tái)python程序處理請(qǐng)求時(shí)間過長(zhǎng)
2 mysql慢查詢
通過查看監(jiān)控：
1 cpu和內(nèi)存的使用，都在正常范圍
2 后臺(tái)程序訪問正常
3 MySQL沒有慢查詢

結(jié)果：
經(jīng)過詢問老大后得知，這個(gè)nginx為查詢違章的api，用戶提交查詢后， python就去數(shù)據(jù)庫(kù)或者交通局的網(wǎng)站查詢。這個(gè)查詢會(huì)有消耗一定的時(shí)間，所以，用戶會(huì)主動(dòng)斷開連接
解決問題：
proxy_ignore_client_abort on; #讓代理服務(wù)端不要主動(dòng)關(guān)閉客戶端的連接。

默認(rèn) proxy_ignore_client_abort 是關(guān)閉的，此時(shí)在請(qǐng)求過程中如果客戶端端主動(dòng)關(guān)閉請(qǐng)求或者客戶端網(wǎng)絡(luò)斷掉，那么 Nginx 會(huì)記錄 499，同時(shí) request_time 是「后端已經(jīng)處理」的時(shí)間，而upstream_response_time 為“-“ (已驗(yàn)證)。

如果使用了 proxy_ignore_client_abort on ;
那么客戶端主動(dòng)斷掉連接之后，Nginx 會(huì)等待后端處理完(或者超時(shí))，然后記錄「后端的返回信息」到日志。所以，如果后端返回 200，就記錄 200 ；如果后端放回 5XX ，那么就記錄 5XX 。
如果超時(shí)(默認(rèn)60s，可以用 proxy_read_timeout 設(shè)置)，Nginx 會(huì)主動(dòng)斷開連接，記錄 504
注：只在做反向代理的時(shí)候加入，作為其他服務(wù)器的時(shí)候，關(guān)閉為好，默認(rèn)設(shè)置是關(guān)閉的！

? ? ? 本文轉(zhuǎn)自Tenderrain 51CTO博客，原文鏈接：http://blog.51cto.com/tenderrain/2045110，如需轉(zhuǎn)載請(qǐng)自行聯(lián)系原作者

總結(jié)

以上是生活随笔為你收集整理的服务器排障 之 nginx 499 错误的解决的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。