一、背景

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

二、499代碼代表了什么

? nginx返回499錯(cuò)誤，那么我們就到nginx的源碼里面看看，是否存在499返回代碼的解釋呢？通過(guò)在nginx的源碼進(jìn)行查找，發(fā)現(xiàn)有一段這樣的代碼：

#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對(duì)應(yīng)的就是499代碼，其表示了client has closed connection，即說(shuō)明了是客戶(hù)端已經(jīng)關(guān)閉了連接。

? 那么為什么客戶(hù)端會(huì)主動(dòng)去關(guān)閉連接呢？其實(shí)最簡(jiǎn)單的解釋就是因?yàn)榉?wù)端處理時(shí)間過(guò)長(zhǎng)，然后客戶(hù)端無(wú)法等到服務(wù)端處理完成，然后就會(huì)去主動(dòng)關(guān)閉連接，然后代理就會(huì)為我們返回499錯(cuò)誤。

? 在進(jìn)行資料查詢(xún)后，我們可以總結(jié)出一般有幾種情況，可能造成499錯(cuò)誤：

? 1）客戶(hù)端在服務(wù)端響應(yīng)前確實(shí)主動(dòng)關(guān)閉了連接；

? 2）客戶(hù)端在連接服務(wù)端進(jìn)行業(yè)務(wù)的過(guò)程中，網(wǎng)絡(luò)發(fā)生了中斷，出現(xiàn)了連接超時(shí)；

3）兩次提交post過(guò)快，nginx會(huì)認(rèn)為是不安全的連接，主動(dòng)拒絕了客戶(hù)端的連接（往往是有人故意攻擊，消耗服務(wù)器資源）；

4）php的進(jìn)程數(shù)量不夠用，需要調(diào)整php的進(jìn)程數(shù)量；

三、如何處理499問(wèn)題

? 在nginx的配置中有一個(gè)參數(shù)為：proxy_ignore_client_abort

? 該參數(shù)的含義是：確定在客戶(hù)端關(guān)閉連接時(shí)，是否關(guān)閉與代理服務(wù)器的連接，而不再等待響應(yīng)。

? 該值的默認(rèn)值為off，此時(shí)則代表在發(fā)生交易的過(guò)程中，如果客戶(hù)端無(wú)論是發(fā)生了主動(dòng)關(guān)閉連接、客戶(hù)端網(wǎng)絡(luò)中斷、訪問(wèn)服務(wù)超時(shí)、服務(wù)器未處理的情況，那么 Nginx 都會(huì)記錄 499；這樣則可能會(huì)存在一個(gè)問(wèn)題就是可能無(wú)法真實(shí)反應(yīng)客戶(hù)端服務(wù)訪問(wèn)的真實(shí)情況。

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

1、如果后端返回200，就記錄200 ；
2、如果后端返回5XX ，那么就記錄 5XX；
3、如果超時(shí)(默認(rèn)60s，可以用 proxy_read_timeout 和proxy_send_timeout設(shè)置)，Nginx 會(huì)主動(dòng)斷開(kāi)連接，記錄504。

這樣則可以將訪問(wèn)異常的真實(shí)問(wèn)題反應(yīng)出來(lái)。

? 因此，我們可以通過(guò)在http域、server域、location域內(nèi)加入：

```
proxy_ignore_client_abort on
```

四、風(fēng)險(xiǎn)

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

五、結(jié)論

? 結(jié)合上述的分析，考慮到風(fēng)險(xiǎn)，我們可以得出以下結(jié)論，如果我們的機(jī)器只存在單機(jī)環(huán)境或者無(wú)冗余環(huán)境的時(shí)候，我們盡可能的不要去設(shè)置這個(gè)參數(shù)，從而避免服務(wù)器被壓垮的風(fēng)險(xiǎn)；當(dāng)我們有足夠的環(huán)境做冗余的時(shí)候或者在前端有負(fù)載均衡對(duì)連接進(jìn)行分發(fā)負(fù)載的時(shí)候，我們則可以考慮打開(kāi)該參數(shù)，從而便于運(yùn)維人員分析問(wèn)題異常。

到此這篇關(guān)于nginx代理返回代碼499問(wèn)題分析與處理的文章就介紹到這了,更多相關(guān)nginx返回代碼499內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論