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 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個子進程。 |
