1. 首頁 > 生活百科 > >

nginx 客戶端返回499的錯誤碼

生活百科

我們服務器客戶端一直有返回錯誤碼499的日志，以前覺得比例不高，就沒有仔細查過，最近有領導問這個問題，為什么耗時只有0.0幾秒，為啥還499了？最近幾天就把這個問題跟蹤定位了一下，這里做個記錄
網絡架構和背景我們服務架構和錯誤碼是上面這樣的，上游服務日志沒有記錄，無法確定kong到上游服務的連接和請求細節 。
kong上的日志rsp_cost:0.041rsp_length:0rsp_status:499ups_rsp_cost:-ups_rsp_length:0ups_rsp_status:-waf上的日志rsp_cost:1.045rsp_length:0rsp_status:499ups_rsp_cost:-ups_rsp_length:0ups_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的錯誤碼】

推薦閱讀