我們服務(wù)器客戶端一直有返回錯(cuò)誤碼499的日志，以前覺得比例不高，就沒有仔細(xì)查過，最近有領(lǐng)導(dǎo)問這個(gè)問題，為什么耗時(shí)只有0.0幾秒，為啥還499了？最近幾天就把這個(gè)問題跟蹤定位了一下，這里做個(gè)記錄

網(wǎng)絡(luò)架構(gòu)和背景

我們服務(wù)架構(gòu)和錯(cuò)誤碼是上面這樣的，上游服務(wù)日志沒有記錄，無法確定kong到上游服務(wù)的連接和請(qǐng)求細(xì)節(jié)。

kong上的日志
rsp_cost:0.041
rsp_length:0
rsp_status:499
ups_rsp_cost:-
ups_rsp_length:0
ups_rsp_status:-

waf上的日志
rsp_cost:1.045
rsp_length:0
rsp_status:499
ups_rsp_cost:-
ups_rsp_length:0
ups_rsp_status:-

看日志，兩個(gè)負(fù)載均衡的現(xiàn)象一毛一樣，kong upstream到web服務(wù)上，不太確定是upstream 鏈接的問題或者是讀寫數(shù)據(jù)的問題，或者是kong自己的問題，根本就沒有反向代理到上游服務(wù)

上游服務(wù)抓包

打算在上游服務(wù)上抓一下包，看看請(qǐng)求是在kong上出問題了，根本沒到上游服務(wù)，還是說已經(jīng)到了上游服務(wù)，上游服務(wù)出問題了。

83是kong的ip，82是上游服務(wù)的ip
可以看到，83首先發(fā)了fin包，表示要斷開連接,之后82也回復(fù)了fin的ack包，之后82還在發(fā)送數(shù)據(jù)包，過了大概0.18秒，82才給83發(fā)了fin ack包，表示可以斷開連接了。這時(shí)候由于83早就斷開了連接，在這個(gè)中間的包，83回復(fù)了RST，我們使用的是長鏈接，83斷開連接之后，新的連接已經(jīng)復(fù)用這個(gè)TCP連接了，這時(shí)候83只能回復(fù)RST。大概過程就是這樣的。

kong為什么要斷開連接？
由于我們使用upstream是長鏈接，猜測(cè)了很多種可能

• keepalive_requests 超過keepalive_requests個(gè)請(qǐng)求后就會(huì)關(guān)閉長鏈接
• keepalive_time 超過keepalive_time時(shí)間后就會(huì)關(guān)閉長鏈接
• keepalive_timeout 打開上游服務(wù)的超時(shí)時(shí)間，連接超過keepalive_timeout就認(rèn)為上游服務(wù)已經(jīng)不可用了，這個(gè)參數(shù)就直接排除了，抓包已經(jīng)看到請(qǐng)求已經(jīng)到了上游服務(wù)

最后都放棄了這個(gè)配置，覺得Nginx應(yīng)該會(huì)處理完請(qǐng)求之后再受到keepalive_requests keepalive_time的限制關(guān)閉連接，不可能請(qǐng)求處理一半然后直接主動(dòng)關(guān)閉連接，還有一個(gè)原因，我們的Nginx版本是1.13，也沒有這些配置可以修改。

負(fù)載均衡的問題？

最后懷疑是waf上的問題，waf上請(qǐng)求量太大，沒去waf機(jī)器上抓包，猜測(cè)waf抓包跟kong的結(jié)果是一樣的，然后向前推測(cè)waf為什么要斷開連接，猜測(cè)是不是客戶端斷開了連接，如果是客戶端斷開連接的話，所有的看到的日志現(xiàn)象就是通的。
為了驗(yàn)證這個(gè)猜測(cè)，我們?cè)跍y(cè)試環(huán)境模擬了一下客戶端主動(dòng)斷開連接的操作。
我們先在的上游服務(wù)上模擬了一個(gè)耗時(shí)的請(qǐng)求，然后再?zèng)]有返回結(jié)果的時(shí)候主動(dòng)斷開請(qǐng)求。

class TestController extends BaseController
{
    public function actionTest()
    {
        sleep(3);
        return $this->response->success(array("test","geekbang","es"));
    }
}

然后我們?cè)诮K端上使用curl請(qǐng)求接口,在三秒之內(nèi)取消請(qǐng)求。
curl https://test.com/test/test/testctrl+C 取消請(qǐng)求
然后觀察waf的日志，以及kong的日志，跟生產(chǎn)出現(xiàn)的499錯(cuò)誤碼表現(xiàn)是一樣的。
基本上確定是客戶端主動(dòng)斷開連接引起的。

修改配置 Nginx的配置

看一下proxy_ignore_client_abort說明

Syntax:	proxy_ignore_client_abort on | off;
Default:	
proxy_ignore_client_abort off;
Determines whether the connection with a proxied server should be closed when a client closes the connection without waiting for a response.

確定當(dāng)客戶端在不等待響應(yīng)的情況下關(guān)閉連接時(shí)，是否應(yīng)該關(guān)閉與代理服務(wù)器的連接。
客戶端不等待響應(yīng)關(guān)閉連接時(shí)，默認(rèn)會(huì)關(guān)閉與代理服務(wù)器的連接，改為on就是代理服務(wù)器不關(guān)閉，直到代理服務(wù)器處理完請(qǐng)求。
在kong上修改配置
proxy_ignore_client_abort on
改了一臺(tái)機(jī)器，觀察了一天，確定了是因?yàn)檫@個(gè)配置，后面把兩臺(tái)機(jī)器都改了之后就沒有再出現(xiàn)499的錯(cuò)誤碼。修改了這個(gè)配置之后，盡管錯(cuò)誤碼消失了，但是無效的請(qǐng)求會(huì)增加上游服務(wù)的壓力，本來這個(gè)請(qǐng)求已經(jīng)無意義被客戶端關(guān)閉了，然后上游服務(wù)也被關(guān)閉了。打開之后，上游服務(wù)不會(huì)被關(guān)閉，直到請(qǐng)求處理完畢，有利有弊，需要權(quán)衡和取舍。

到此這篇關(guān)于nginx 客戶端返回499的錯(cuò)誤碼的文章就介紹到這了,更多相關(guān)nginx返回499錯(cuò)誤碼內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！