淺析nginx 使用者端返回499的錯誤碼的問題

2022-11-01 14:04:11

網路架構和背景

我們服務架構和錯誤碼是上面這樣的，上游服務紀錄檔沒有記錄，無法確定kong到上游服務的連線和請求細節。

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:-

看紀錄檔，兩個負載均衡的現象一毛一樣，kong upstream到web服務上，不太確定是upstream 連結的問題或者是讀寫資料的問題，或者是kong自己的問題，根本就沒有反向代理到上游服務

上游服務抓包

打算在上游服務上抓一下包，看看請求是在kong上出問題了，根本沒到上游服務，還是說已經到了上游服務，上游服務出問題了。

83是kong的ip，82是上游服務的ip
可以看到，83首先發了fin包，表示要斷開連線,之後82也回覆了fin的ack包，之後82還在傳送封包，過了大概0.18秒，82才給83發了fin ack包，表示可以斷開連線了。這時候由於83早就斷開了連線，在這個中間的包，83回覆了RST，我們使用的是長連結，83斷開連線之後，新的連線已經複用這個TCP連線了，這時候83只能回覆RST。大概過程就是這樣的。

kong為什麼要斷開連線？
由於我們使用upstream是長連結，猜測了很多種可能

keepalive_requests 超過keepalive_requests個請求後就會關閉長連結
keepalive_time 超過keepalive_time時間後就會關閉長連結
keepalive_timeout 開啟上游服務的超時時間，連線超過keepalive_timeout就認為上游服務已經不可用了，這個引數就直接排除了，抓包已經看到請求已經到了上游服務

最後都放棄了這個設定，覺得Nginx應該會處理完請求之後再受到keepalive_requests keepalive_time的限制關閉連線，不可能請求處理一半然後直接主動關閉連線，還有一個原因，我們的Nginx版本是1.13，也沒有這些設定可以修改。

負載均衡的問題？

最後懷疑是waf上的問題，waf上請求量太大，沒去waf機器上抓包，猜測waf抓包跟kong的結果是一樣的，然後向前推測waf為什麼要斷開連線，猜測是不是使用者端斷開了連線，如果是使用者端斷開連線的話，所有的看到的紀錄檔現象就是通的。
為了驗證這個猜測，我們在測試環境模擬了一下使用者端主動斷開連線的操作。
我們先在的上游服務上模擬了一個耗時的請求，然後再沒有返回結果的時候主動斷開請求。

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

然後我們在終端上使用curl請求介面,在三秒之內取消請求。
curl https://test.com/test/test/testctrl+C 取消請求
然後觀察waf的紀錄檔，以及kong的紀錄檔，跟生產出現的499錯誤碼錶現是一樣的。
基本上確定是使用者端主動斷開連線引起的。

修改設定 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.

確定當用戶端在不等待響應的情況下關閉連線時，是否應該關閉與代理伺服器的連線。
使用者端不等待響應關閉連線時，預設會關閉與代理伺服器的連線，改為on就是代理伺服器不關閉，直到代理伺服器處理完請求。
在kong上修改設定
proxy_ignore_client_abort on
改了一臺機器，觀察了一天，確定了是因為這個設定，後面把兩臺機器都改了之後就沒有再出現499的錯誤碼。修改了這個設定之後，儘管錯誤碼消失了，但是無效的請求會增加上游服務的壓力，本來這個請求已經無意義被使用者端關閉了，然後上游服務也被關閉了。開啟之後，上游服務不會被關閉，直到請求處理完畢，有利有弊，需要權衡和取捨。

到此這篇關於nginx 使用者端返回499的錯誤碼的文章就介紹到這了,更多相關nginx返回499錯誤碼內容請搜尋it145.com以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援it145.com！

淺析nginx 使用者端返回499的錯誤碼的問題

目錄

網路架構和背景

上游服務抓包

負載均衡的問題？

修改設定 Nginx的設定

熱門文章