目錄一、背景二、499代碼代表了什么三、如何處理499問題四、風險五、結論一、背景

? 我們通過nginx作為互聯網代理服務器，通過它實現我行內部系統向互聯網系統的接口訪問及調用；但是在使用過程中，不時的會出現大量返回代碼為499的問題(正常訪問返回為200)，甚至有時候部分系統在報499的錯誤時，會影響到某一業務的正常使用。此時，我們也會懷疑nginx代理出現了問題，于是重啟或者重新加載nginx服務。但是比較奇怪的是，如果nginx整個出現了問題，那么為什么會出現某個業務異常而不是在nginx上的所有服務異常呢？于是，我們則需要對為什么nginx會返回499錯誤代碼展開分析和研究。

二、499代碼代表了什么

? nginx返回499錯誤，那么我們就到nginx的源碼里面看看，是否存在499返回代碼的解釋呢？通過在nginx的源碼進行查找，發現有一段這樣的代碼：

#define NGX_HTTP_LAST_4XX 430#define NGX_HTTP_OFF_5XX (NGX_HTTP_LAST_4XX - 400 + NGX_HTTP_OFF_4XX) ngx_string(ngx_http_error_494_page), /* 494, request header too large */ 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 */ ngx_string(ngx_http_error_500_page), ngx_string(ngx_http_error_501_page), ngx_string(ngx_http_error_502_page), ngx_string(ngx_http_error_503_page), ngx_string(ngx_http_error_504_page), ngx_string(ngx_http_error_505_page), ngx_null_string, /* 506 */ ngx_string(ngx_http_error_507_page)

從這里，我們則可以看到ngx_null_string對應的就是499代碼，其表示了client has closed connection，即說明了是客戶端已經關閉了連接。

? 那么為什么客戶端會主動去關閉連接呢？其實最簡單的解釋就是因為服務端處理時間過長，然后客戶端無法等到服務端處理完成，然后就會去主動關閉連接，然后代理就會為我們返回499錯誤。

? 在進行資料查詢后，我們可以總結出一般有幾種情況，可能造成499錯誤：

? 1）客戶端在服務端響應前確實主動關閉了連接；

? 2）客戶端在連接服務端進行業務的過程中，網絡發生了中斷，出現了連接超時；

3）兩次提交post過快，nginx會認為是不安全的連接，主動拒絕了客戶端的連接（往往是有人故意攻擊，消耗服務器資源）；

4）php的進程數量不夠用，需要調整php的進程數量；

三、如何處理499問題

? 在nginx的配置中有一個參數為：proxy_ignore_client_abort

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

? 該值的默認值為off，此時則代表在發生交易的過程中，如果客戶端無論是發生了主動關閉連接、客戶端網絡中斷、訪問服務超時、服務器未處理的情況，那么 Nginx 都會記錄 499；這樣則可能會存在一個問題就是可能無法真實反應客戶端服務訪問的真實情況。

? 而該值改為on的時候，則表示客戶端主動斷掉連接之后，Nginx 會等待后端服務器處理完(或者超時)，然后記錄“后端的返回信息”到日志。因此，會有幾種情況：

1、如果后端返回200，就記錄200 ；2、如果后端返回5XX ，那么就記錄 5XX；3、如果超時(默認60s，可以用 proxy_read_timeout 和proxy_send_timeout設置)，Nginx 會主動斷開連接，記錄504。

這樣則可以將訪問異常的真實問題反應出來。

? 因此，我們可以通過在http域、server域、location域內加入：

```proxy_ignore_client_abort on```四、風險

? 根據上面的分析，其實我們可以發現，其實發生499的問題時候的可能性會很多，而且如果出現客戶端在建立連接后主動關閉了連接的情況則會是一種正常的場景。當然，雖然我們可以通過打開proxy_ignore_client_abort的參數來解決499的問題，且可以暴露出客戶端到服務端的真實原因。但是打開該設置后也會存在一定風險，即當有大量瞬間斷開的請求時，后端會默默地全部處理掉，比較浪費資源，且并發壓力比較大時，也有可能造成服務器出現被壓垮宕機的可能。

五、結論

? 結合上述的分析，考慮到風險，我們可以得出以下結論，如果我們的機器只存在單機環境或者無冗余環境的時候，我們盡可能的不要去設置這個參數，從而避免服務器被壓垮的風險；當我們有足夠的環境做冗余的時候或者在前端有負載均衡對連接進行分發負載的時候，我們則可以考慮打開該參數，從而便于運維人員分析問題異常。

到此這篇關于nginx代理返回代碼499問題分析與處理的文章就介紹到這了,更多相關nginx返回代碼499內容請搜索好吧啦網以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持好吧啦網！