背景

nginx 499在服務(wù)端推送流量高峰期長期以來都是存在的，間或還能達到告警閾值觸發(fā)一小波告警，但主觀上一直認(rèn)為499是客戶端主動斷開，可能和推送高峰期的用戶打開推送后很快殺死app有關(guān)，沒有進一步探究問題根源。
然而近期在非高峰期也存在499超過告警閾值的偶發(fā)情況，多的時候一天幾次，少的時候則幾天一次，持續(xù)一般也就數(shù)分鐘，并且該類告警一般集中于一臺api機器，與推送高峰時多臺機器同時499告警明顯不同，不由得腦海中升起了問號，經(jīng)過和小伙伴的共同探究，最后發(fā)現(xiàn)之前對于499是客戶端主動斷開因而和服務(wù)端關(guān)系不大的想當(dāng)然認(rèn)知是錯誤的，這里記錄一下。

499的含義與可能原因

499其實并不是HTTP協(xié)議的標(biāo)準(zhǔn)狀態(tài)碼，而是nginx自定義的狀態(tài)碼，并沒有在nginx官方文檔中找到對該狀態(tài)碼的明確說明，這里引用一個感覺比較專業(yè)的博文上的解釋：

HTTP error 499 simply means that the client shut off in the middle of processing the request through the server. The 499 error code puts better light that something happened with the client, that is why the request cannot be done. So don’t fret: HTTP response code 499 is not your fault at all.

大意是499一般意味著客戶端在HTTP請求還在處理時主動結(jié)束的處理過程--斷開了對應(yīng)的網(wǎng)絡(luò)連接，499一般意味著客戶端側(cè)發(fā)生了一些問題，和服務(wù)端沒有關(guān)系。
以下則是nginx源碼中的注釋說明：

/*
* HTTP does not define the code for the case when a client closed
* the connection while we are processing its request so we introduce
* own code to log such situation when a client has closed the connection
* before we even try to send the HTTP header to it
*/
#define NGX_HTTP_CLIENT_CLOSED_REQUEST     499

意思是nginx引入了自定義的code 499來記錄客戶端斷開連接時nginx還沒有處理完其請求的場景。
回想多年以前首次碰到499場景時在網(wǎng)絡(luò)搜索資料也是看到了類似的解答，所以一直認(rèn)為499和服務(wù)端關(guān)系不大，應(yīng)該都是客戶端的原因。

一個客戶端主動行為導(dǎo)致499的例子

曾經(jīng)遇到過一個搜索聯(lián)想接口，其499比例比其他api高上幾十倍--一騎絕塵，單看該api基本上長期位于告警閾值之上，也追蹤過其具體異常原因，最后聯(lián)合客戶端小伙伴給出了結(jié)論：搜索聯(lián)想接口的499比例偏高時正常的，因為：

• 該api的調(diào)用場景是用戶在搜索框輸入搜索詞時，用戶每輸入一個字符都會立刻用最新的輸入調(diào)用api并將返回的聯(lián)想結(jié)果展示給用戶，以此達到一個近實時搜索聯(lián)想的功能。
• 既然每次用戶輸入新字符都觸發(fā)了最新的api調(diào)用請求，那即便之前的調(diào)用請求還在進行中，客戶端也應(yīng)該直接結(jié)束這些已無實際作用的舊請求，這反映在nginx log上就是客戶端主動斷開了連接的499。

所以搜索聯(lián)想api雖然有異于普通api的高比例499，卻是完全合理的，客戶端要負(fù)主動斷開連接的責(zé)任，但是并沒有做錯任何事情，服務(wù)端也沒有任何問題。

一個客戶端被動行為導(dǎo)致499的例子

另一個之前認(rèn)為客戶端行為導(dǎo)致499的例子是推送高峰，部分用戶在通過推送打開app后可能會秒殺app，而推送高峰時期一般服務(wù)端壓力比較大本身響應(yīng)就會比平峰時期慢一些，此時有些api請求可能還正在進行中，此時用戶殺死了app--app含冤而死無能為力--對應(yīng)連接自然就被OS斷開回收了，于是也導(dǎo)致了499，這種場景下服務(wù)端也是沒有問題的。

服務(wù)端問題可能導(dǎo)致499？

通過上面兩個例子乍看下去，499都是客戶端側(cè)的原因，無論是其主動還是被動行為，也正是這兩個例子加深了博主心中對于499服務(wù)端應(yīng)該無責(zé)任的意識。
總結(jié)服務(wù)端出錯可能導(dǎo)致的nginx錯誤碼，主要應(yīng)該是以下幾個場景：

• 500： 內(nèi)部錯誤，一般為請求參數(shù)直接導(dǎo)致了upstream 的處理線程執(zhí)行代碼出錯，業(yè)務(wù)代碼或者框架直接返回 Internal Error
• 502： 一般為upstream server直接掛了無法連接，nginx無法訪問upstream所以返回 Bad Gateway
• 503： upstream負(fù)載過高--但是沒掛，直接返回了Service Unavailable
• 504: upstream處理請求時間過長，nginx等待upstream返回超時返回Gateway Timeout

所以無論是代碼執(zhí)行出錯、服務(wù)掛了、服務(wù)過于繁忙、請求處理耗時過長導(dǎo)致HTTP請求失敗，都是返回的5XX，壓根不會觸發(fā)499。
一般情況來說確實是這樣的，但是這次新出現(xiàn)的平峰499并非一般情況，在網(wǎng)上查找資料時時有人提出過nginx 499可能是服務(wù)端處理耗時過長導(dǎo)致客戶端超時后主動斷開，但是這種情況按照上面的描述不應(yīng)該屬于場景4-- upstream處理請求時間過長，nginx返回504才對嗎？
所以看上去服務(wù)端處理耗時過長既可能導(dǎo)致客戶端主動斷開的499也可能導(dǎo)致nginx返回Gateway Timeout的504，那導(dǎo)致這個區(qū)別的關(guān)鍵因素是什么？
簡單來說就是如果客戶端先斷開被nginx檢測到那就是499，而如果upstream 耗時過長超時先被nginx判定就是504，所以關(guān)鍵就是nginx對于upstream 超時的時間設(shè)置，捋到這里趕緊去看了下nginx的超時相關(guān)配置，嗯，沒有明確配置相關(guān)超時時間--！

nginx中的504判定相關(guān)超時配置

由于api與nginx是通過uwsgi協(xié)議通信，因此關(guān)鍵的超時配置參數(shù)如下：

Syntax:	uwsgi_connect_timeout time;
Default:	
uwsgi_connect_timeout 60s;
Context:	http, server, location
Defines a timeout for establishing a connection with a uwsgi server. It should be noted that this timeout cannot usually exceed 75 seconds.
Syntax:	uwsgi_send_timeout time;
Default:	
uwsgi_send_timeout 60s;
Context:	http, server, location
Sets a timeout for transmitting a request to the uwsgi server. The timeout is set only between two successive write operations, not for the transmission of the whole request. If the uwsgi server does not receive anything within this time, the connection is closed.
Syntax:	uwsgi_read_timeout time;
Default:	
uwsgi_read_timeout 60s;
Context:	http, server, location
Defines a timeout for reading a response from the uwsgi server. The timeout is set only between two successive read operations, not for the transmission of the whole response. If the uwsgi server does not transmit anything within this time, the connection is closed.

在未明確指定的情況下其超時時間均默認(rèn)為60s，簡單來說（實際情況更復(fù)雜一些但這里不進一步探討）只有在upstream處理請求耗時超過60s的情況下nginx才能判定其Gateway Timeout 并按照504處理，然而客戶端設(shè)置的HTTP請求超時時間其實只有15s--這其中還包括外網(wǎng)數(shù)據(jù)傳輸?shù)臅r間，于是問題來了：每一個服務(wù)端處理耗時超過15s的請求，nginx由于還沒達到60s的超時閾值不會判定504，而客戶端則會由于超過本地的15s超時時間直接斷開連接，nginx于是就會記錄為499。
通過回查nginx log，非高峰期的499告警時段確實是存在單臺upstream 請求處理緩慢，耗時過長，于是可能導(dǎo)致：

• 用戶在需要block等待請求的頁面等待雖然不到15s但是已經(jīng)不耐煩了，直接采取切頁面或者殺死app重啟的方式結(jié)束當(dāng)前請求。
• 用戶耐心等待了15s、或者非阻塞的后臺HTTP請求超過了15s超過超時閾值主動斷開連接結(jié)束了當(dāng)前請求。

服務(wù)端耗時過長導(dǎo)致的499

上面已經(jīng)知道近期新出現(xiàn)的單臺upstream 偶發(fā)499是由于響應(yīng)緩慢引起的，既然是由于客戶端超時時間(15s)遠小于nginx upstream超時時間(60s)引起的，這應(yīng)該屬于一個明顯的配置不當(dāng)，會導(dǎo)致三個明顯的問題：

• 將用戶由于各種原因(如殺app)很快主動斷開連接導(dǎo)致的499與客戶端達到超時時間(這里是15s)導(dǎo)致的499混在了一起，無法區(qū)分客戶端責(zé)任與服務(wù)端責(zé)任導(dǎo)致499問題。
• 對于nginx判定為499的請求，由于認(rèn)為是客戶端主動斷開，不會被認(rèn)為是服務(wù)端導(dǎo)致的unsuccessful attempt而被計入用于failover判定的max_fails計數(shù)中，所以即便一個upstream大量觸發(fā)了499，nginx都不會將其從可用upstream中摘除，相當(dāng)于摘除不可用節(jié)點的功能失效，而由于負(fù)載過高導(dǎo)致499的upstream收到的請求依然不斷增加最終可能導(dǎo)致更大的問題。
• 對于判定為499的請求，也是由于不會被認(rèn)為是unsuccessful attempt，所以uwsgi_next_upstream這一配置也不會work，于是當(dāng)?shù)谝粋€處理請求的upstream耗時過長超時后，nginx不會嘗試將其請求轉(zhuǎn)發(fā)為下一個upstream嘗試處理后返回，只能直接失敗。

那是不是把客戶端超時時間調(diào)大？或者把nginx upstream超時時間調(diào)小解決呢？
調(diào)大客戶端超時時間當(dāng)然是不合理的，任何用戶請求15s還未收到響應(yīng)肯定是有問題的，所以正確的做法應(yīng)該是調(diào)小upstream的超時時間，一般來說服務(wù)端對于客戶端請求處理時間應(yīng)該都是在數(shù)十、數(shù)百ms之間，超過1s就已經(jīng)屬于超長請求了，所以不但默認(rèn)的60s不行，客戶端設(shè)置的15s也不能用于upstream的超時判定。
最終經(jīng)過綜合考慮服務(wù)端各api的耗時情況，先敲定了一個upstream 5s的超時時間配置--由于之前沒有經(jīng)驗首次修改步子不邁太大，觀察一段時間后繼續(xù)調(diào)整，這樣做已經(jīng)足以很大程度解決以上的3個問題：

• 將用戶由于各種原因(如殺app)很快主動斷開連接導(dǎo)致的499與nginx達到upstream超時時間時主動結(jié)束的504區(qū)分開了。
• 504會被納入max_fails計算，觸發(fā)nginx摘除失敗節(jié)點邏輯，在單臺機器故障響應(yīng)緩慢時可以被識別出來暫時摘除出可用節(jié)點列表，防止其負(fù)載進一步加大并保證后續(xù)請求均被正?？捎霉?jié)點處理返回。
• 當(dāng)nginx等待upstream處理達到5s觸發(fā)超時時，其會按照uwsgi_next_upstream配置嘗試將請求(默認(rèn)僅限冪等的GET請求)轉(zhuǎn)交給下一個upstream嘗試處理后返回，這樣在單一upstream由于異常負(fù)載較高超時時，其他正常的upstream可以作為backup兜底處理其超時請求，這里客戶端原本等待15s超時的請求一般在5~10s內(nèi)可以兜底返回。

通過proxy_ignore_client_abort配置解決499問題？

在網(wǎng)上查找資料時還有網(wǎng)友提出解除nginx 499問題的一個思路是設(shè)置proxy_ignore_client_abort參數(shù)，該參數(shù)默認(rèn)為off，將其設(shè)置為on 后，對于客戶端主動斷開請求的情況，nginx會ignore而以upstream實際返回的狀態(tài)為準(zhǔn)，nginx官方文檔說明如下：

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

但是在客戶端主動斷開連接時，設(shè)置這個參數(shù)的意義除了使nginx log中記錄的狀態(tài)碼完全按照upstream返回確定，而非表示客戶端斷連的499之外，對于實際問題解決完全沒有任何幫助，感覺頗有把頭埋進沙子的鴕鳥風(fēng)格，不知道這個參數(shù)設(shè)置到底會有什么實用的場景。

非高峰時期單個upstream偶發(fā)響應(yīng)緩慢、導(dǎo)致超時的原因

這是個好問題，這個問題是近期才出現(xiàn)的，在解決了上面說的nginx錯配問題后嘗試排查這個問題，從現(xiàn)象上看應(yīng)該是某些特定請求觸發(fā)了upsteam CPU飆升，響應(yīng)緩慢后進一步影響了后續(xù)請求的處理，最終導(dǎo)致所有請求響應(yīng)緩慢觸發(fā)客戶端499。
在nginx錯配問題解決后，再次出現(xiàn)這種單臺upstream緩慢超時情況后，nginx會很快通過failover摘除掉問題upstream避免情況進一步惡化，而對于首次訪問問題upstream超時的GET請求也會backup轉(zhuǎn)發(fā)至其他可用upstream處理后返回，已經(jīng)很大程度上降低了此類異常情況的影響。
最終，修正配置后單upstream的偶發(fā)異常會以幾天一次的頻率觸發(fā)部分POST api的少量504閾值告警，其問題的根本原因還在探尋中。

總結(jié)

人生有太多錯誤的想當(dāng)然，nginx 499一般是客戶端責(zé)任便是一個例證，對于線上長期存在的少量異常告警，還是要懷有一絲敬畏之心，小心溫水煮青蛙，在時間允許的情況下多探究、多思考。

轉(zhuǎn)載請注明出處，原文地址：https://www.cnblogs.com/AcAc-t/p/nginx_499_and_504_for_uwsgi.html

參考資料

https://www.belugacdn.com/499-error-code/

https://juejin.cn/post/6844903876315873293http://nginx.org/en/docs/

http/ngx_http_uwsgi_module.html#uwsgi_read_timeout

https://www.cnblogs.com/AcAct/p/nginx_499_and_504_for_uwsgi.html

http://nginx.org/en/docs/http/ngx_http_upstream_module.html

http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_ignore_client_abort

到此這篇關(guān)于記一次nginx配置不當(dāng)引發(fā)的499與failover 機制失效問題的文章就介紹到這了,更多相關(guān)nginx配置不當(dāng)引發(fā)的499與failover 機制失效 內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！