日誌記錄中http狀態碼出現499錯誤有多種情況，我遇到的一種情況是nginx反代到乙個永遠打不開的後端，就這樣了，日誌狀態記錄是499、傳送位元組數是0。
老是有使用者反映**系統時好時壞，因為線上的產品很長時間沒有修改，所以前端程式的問題基本上可以排除，於是就想著是get方式呼叫的介面不穩定，問了相關人員，說沒有問題，為了拿到確切證據，於是我問相關人員要了nginx伺服器的日誌檔案（awstats日誌），分析後發現日誌中很多錯誤碼為499的錯誤，約佔整個日誌檔案的1%，而它只佔全部報錯的70%左右（全部報錯見下圖），那麼所有報錯加起來就要超過1%了，這個量還是特別大的。
499錯誤是什麼？讓我們看看nginx的原始碼中的定義：
可以看到，499對應的是 「client has closed connection」。這很有可能是因為伺服器端處理的時間過長，客戶端「不耐煩」了。
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個子程序。
Nginx的HTTP 499狀態碼及問題處理
1 遇到的問題 2 處理方法 499錯誤是什麼？讓我們看看nginx的原始碼中的定義 可以看到，499對應的是 client has closed connection 這很有可能是因為伺服器端處理的時間過長，客戶端 不耐煩 了。測試nginx發現如果兩次提交post過快就會出現499的情況，看來是...
狀態碼499 HTTP狀態碼最全彙總
狀態碼的職責是當客戶端向伺服器端傳送請求時，描述返回的請求結果。借助狀態碼，使用者可以知道伺服器端是正常處理了請求，還是出現了錯誤。注意，狀態碼是服務端向客戶端傳送的反映響應結果的標識碼。下面是常見的幾種狀態碼 伺服器有一組用來表示成功的狀態碼，分別對應於不同型別的請求。重定向狀態碼要麼告訴客戶端使...
http的499狀態碼是什麼鬼？
在排查mysql鎖表的情況時，發現總是出現兩次相鄰的同樣請求。而且第一次的事務基本都成功，第二次的失敗 繼續分析得出，因為 時間比較長，超過了30s，使用者無法忍受。重新整理了頁面或者關閉重新提交同樣的修改資料。但第一次的事務還在進行中。結果就出現了,為了驗證自己的想法，對499進行了模擬 sqls...