http://blog.51cto.com/yucanghai/1713803

問題描述：

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

注：只在做反向代理的時候加入，作為其他伺服器的時候，關閉為好，預設設定是關閉的！