發現 需要 Nginx訪問日誌 均衡器 不想 關於 null AD ear

Web服務器在用著nginx，在日誌中偶爾會看到有499這個錯誤。 rfc2616中，400～500間的錯誤碼僅定義到了417，所以499應該是nginx自己定義的。後來想到讀讀nginx代碼，疑問立解。 查看nginx源代碼的方法： 1.解壓nginx-1.4.7.tar.gz tar zxf nginx-1.4.7.tar.gz 2.查找499關鍵字： 在nginx源碼中grep一下499（現在看源碼習慣用grep大法），得到如下結果： # cd nginx-1.4.7 # grep 499 -r * 發現在src/http/ngx_http_special_response.c文件中有關於499的解釋 找到src/http/ngx_http_special_response.c 這個文件，裏面定義了不少http錯誤碼以及相應的返回。註意到有下面這樣的註釋：

可以看到，499對應的是 “client has closed connection”。這很有可能是因為服務器端處理的時間過長，客戶端“不耐煩”了。要解決此問題，就需要在程序上面做些優化了。

除了499，nginx還定義了495/496/497/498 這幾個Status Codes，相應的意義也在上面的註釋中可以看到。開源的東西，可以隨時翻看源碼，這一點很棒。

========================================================================================================= 參考 http://www.lc365.net/blog/b/23997/

HTTP 499 狀態碼 nginx下 499錯誤

日誌記錄中HTTP狀態碼出現499錯誤有多種情況，我遇到的一種情況是nginx反代到一個永遠打不開的後端，就這樣了，日誌狀態記錄是499、發送字節數是0。 老是有用戶反映網站系統時好時壞，因為線上的產品很長時間沒有修改，所以前端程序的問題基本上可以排除，於是就想著是Get方式調用的接口不穩定，問了相關人員，說沒有問題，為了拿到確切證據，於是我問相關人員要了nginx服務器的日誌文件（awstats日誌），分析後發現日誌中很多錯誤碼為499的錯誤，約占整個日誌文件的1%，而它只占全部報錯的70%左右（全部報錯見下圖），那麽所有報錯加起來就要超過1%了，這個量還是特別大的。 499錯誤是什麽？讓我們看看NGINX的源碼中的定義： ngx_string(ngx_http_error_495_page), /* 495, https certificate error */ ngx_string(ngx_http_error_496_page), /* 496, https no certificate */ ngx_string(ngx_http_error_497_page), /* 497, http to https */ ngx_string(ngx_http_error_404_page), /* 498, canceled */ ngx_null_string, /* 499, client has closed connection */ 可以看到，499對應的是 “client has closed connection”。這很有可能是因為服務器端處理的時間過長，客戶端“不耐煩”了。 Nginx 499錯誤的原因及解決方法 打開Nginx的access.log發現在最後一次的提交是出現了HTTP1.1 499 0 -這樣的錯誤，在百度搜索nginx 499錯誤，結果都是說客戶端主動斷開了連接。 但經過我的測試這顯然不是客戶端的問題，因為使用端口+IP直接訪問後端服務器不存在此問題，後來測試nginx發現如果兩次提交post過快就會出現499的情況，看來是nginx認為是不安全的連接，主動拒絕了客戶端的連接. 但搜索相關問題一直找不到解決方法，最後終於在google上搜索到一英文論壇上有關於此錯誤的解決方法： proxy_ignore_client_abort on; Don’t know if this is safe. 就是說要配置參數 proxy_ignore_client_abort on; 表示代理服務端不要主要主動關閉客戶端連接。 以此配置重啟nginx,問題果然得到解決。只是安全方面稍有欠缺，但比總是出現找不到服務器好多了。 還有一種原因是 我後來測試發現 確實是客戶端關閉了連接,或者說連接超時 ,無論你設置多少超時時間多沒用 原來是php進程不夠用了 改善一下php進程數 問題解決 默認測試環境才開5個子進程。

499是nginx的Web服務器軟件擴展的4xx錯誤，只是用於記錄的目的，沒有實際的響應。Nginx 499代表服務端請求還未返回時客戶端主動斷開連接；還有一種情況就是有人攻擊，故意消耗服務端資源。例如我們請求一個費時的python請求，但是客戶端等不了，直接把瀏覽器關了，就會報這個錯。不算是特別需要處理的錯，單獨出現可以不用在意。如果大量出現可以分析下是不是某個請求最近請求時間異常高，適當優化

工具/原料

• nginx

方法/步驟:

1. 1

   proxy_ignore_client_abort的含義。確定在客戶端關閉連接時是否應關閉與代理服務器的連接，而不在等待響應。

   
2. 2

   默認 proxy_ignore_client_abort 是關閉的。此時在請求過程中如果客戶端主動關閉請求、客戶端網絡斷開，那麽 Nginx 會記錄 499。

   
3. 3

   如果使用了proxy_ignore_client_abort on。那麽客戶端主動斷掉連接之後，Nginx 會等待後端服務器處理完(或者超時)，然後記錄“後端的返回信息”到日誌。因此，如果後端返回200，就記錄200 ；如果後端返回5XX ，那麽就記錄 5XX。如果超時(默認60s，可以用 proxy_read_timeout 和proxy_send_timeout設置)，Nginx 會主動斷開連接，記錄504。

4. 4

   怎麽在配置增加proxy_ignore_client_abort on。首先找到配置文件，然後打開它，找到http下的server下的location,把它加進去。配置文件路徑（當你執行 nginx -t 的時候，nginx會去測試你的配置文件語法，並告訴你配置文件是否寫得正確，同時也告訴了你配置文件的路徑)

   
5. 5

   註：不建議使用proxy_ignore_client_abort 來處理這個錯誤。因為這樣當有大量瞬間斷開的請求時，後端會默默地全部處理，比較浪費資源，而且並發壓力比較大時，用這種方法將壓垮機器。這個事情交給 php-fpm 自己來處理其實挺合適。因為 PHP 默認當用戶斷開請求了會中斷請求，如果不想自動中斷請求，使用 ignore_user_abort() 就好了。

   END

方法/步驟2：

1. 盡管NGINX配置了，但60秒後HTTP499錯誤。Nginx上的超時都設置了很大的值（遠遠超過60秒）。這可能是雲服務器設置問題，以AWS為例。如果部署在AWS上時，60秒後連接不斷被丟棄，Nginx訪問日誌中是499。當將錯誤日誌設置為調試模式時，您將看到類似下面的內容。 不清楚為什麽客戶端刪除連接。

   

2. 解決方案。在AWS上有一個負載均衡器（load balancer），你大部分都用了默認的配置，因此它將在60秒後刪除連接。將其更改去配合您的Nginx配置。

   

nginx 499狀態碼