nginx配置不當引發的499與failover機制失效問題怎麼解決

499的意義與可能原因

499其實並不是HTTP協定的標準狀態碼，而是nginx自訂的狀態碼，並沒有在nginx官方文件中找到對該狀態碼的明確說明，這裡引用一個感覺比較專業的博文上的解釋：

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#d at all.

#大意是499一般意味著客戶端在HTTP請求還在處理時主動結束的處理過程--斷開了對應的網路連接，499一般意味著客戶端側發生了一些問題，和服務端沒有關係。

以下則是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場景時在網路搜尋資料也是看到了類似的解答，所以一直認為499和服務端關係不大，應該都是客戶端的原因。

一個客戶端主動行為導致499的例子

曾經遇到過一個搜尋聯想接口，其499比例比其他api高上幾十倍--一騎絕塵，單看該api基本上長期位於告警閾值之上，也追蹤過其具體異常原因，最後聯合客戶端小夥伴給出了結論：搜尋聯想介面的499比例偏高時正常的，因為：

該api的呼叫場景是用戶在搜尋框輸入搜尋字詞時，用戶每輸入一個字元都會立刻用最新的輸入呼叫api並將傳回的聯想結果展示給用戶，以此達到一個近實時搜尋聯想的功能。
既然每次使用者輸入新字元都觸發了最新的api呼叫請求，即便先前的呼叫請求還在進行中，客戶端也應該直接結束這些已無實際作用的舊請求，這反映在nginx log上就是客戶端主動斷開了連線的499。
所以搜尋聯想api雖然有異於普通api的高比例499，卻是完全合理的，客戶端要負主動斷開連線的責任，但是並沒有做錯任何事情，服務端也沒有任何問題。

一個客戶端被動行為導致499的例子

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

服務端問題可能導致499？

透過上面兩個例子乍看下去，499都是客戶端側的原因，無論是其主動還是被動行為，也正是這兩個例子加深了博主心中對於499服務端應該無責任的意識。

總結服務端出錯可能導致的nginx錯誤碼，主要應該是以下幾個場景：

500： 內部錯誤，一般為請求參數直接導致了upstream 的處理線程執行程式碼出錯，業務代碼或框架直接返回Internal Error
502： 一般為upstream server直接掛了無法連接，nginx無法存取upstream所以返回Bad Gateway
#503：upstream負載過高--但沒掛，直接回傳了Service Unavailable
504: upstream處理請求時間過長，nginx等待upstream返回逾時返回Gateway Timeout
所以無論是程式碼​​執行出錯、服務掛了、服務過於繁忙、請求處理耗時過長導致HTTP請求失敗，都是傳回的5XX，壓根不會觸發499。

一般情況來說確實是這樣的，但是這次新出現的平峰499並非一般情況，在網上查找資料時時有人提出過nginx 499可能是服務端處理耗時過長導致客戶端超時後主動斷開，但是這種情況按照上面的描述不應該屬於場景4-- upstream處理請求時間過長，nginx返回504才對嗎？

所以看上去服務端處理耗時過長既可能導致客戶端主動斷開的499也可能導致nginx返回Gateway Timeout的504，那導致這個區別的關鍵因素是什麼？
簡單來說就是如果客戶端先斷開被nginx檢測到那就是499，而如果upstream 耗時過長超時先被nginx判定就是504，所以關鍵就是nginx對於upstream 超時的時間設置，捋到這裡趕快去看了下nginx的超時相關配置，嗯，沒有明確配置相關超時時間--！

nginx中的504判定相關逾時配置

由於api與nginx是透過uwsgi協定通信，因此關鍵的超時配置參數如下：

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.

在未明确指定的情况下其超时时间均默认为60s，简单来说（实际情况更复杂一些但这里不进一步探讨）只有在upstream处理请求耗时超过60s的情况下nginx才能判定其Gateway Timeout 并按照504处理，然而客户端设置的HTTP请求超时时间其实只有15s--这其中还包括外网数据传输的时间，于是问题来了：每一个服务端处理耗时超过15s的请求，nginx由于还没达到60s的超时阈值不会判定504，而客户端则会由于超过本地的15s超时时间直接断开连接，nginx于是就会记录为499。
通过回查nginx log，非高峰期的499告警时段确实是存在单台upstream 请求处理缓慢，耗时过长，于是可能导致：

• 用户在需要block等待请求的页面等待虽然不到15s但是已经不耐烦了，直接采取切页面或者杀死app重启的方式结束当前请求。

• 用户耐心等待了15s、或者非阻塞的后台HTTP请求超过了15s超过超时阈值主动断开连接结束了当前请求。

服务端耗时过长导致的499

上面已经知道近期新出现的单台upstream 偶发499是由于响应缓慢引起的，既然是由于客户端超时时间(15s)远小于nginx upstream超时时间(60s)引起的，这应该属于一个明显的配置不当，会导致三个明显的问题：

• 将用户由于各种原因(如杀app)很快主动断开连接导致的499与客户端达到超时时间(这里是15s)导致的499混在了一起，无法区分客户端责任与服务端责任导致499问题。

• 对于nginx判定为499的请求，由于认为是客户端主动断开，不会被认为是服务端导致的unsuccessful attempt而被计入用于failover判定的max_fails计数中，所以即便一个upstream大量触发了499，nginx都不会将其从可用upstream中摘除，相当于摘除不可用节点的功能失效，而由于负载过高导致499的upstream收到的请求依然不断增加最终可能导致更大的问题。

• 对于判定为499的请求，也是由于不会被认为是unsuccessful attempt，所以uwsgi_next_upstream这一配置也不会work，于是当第一个处理请求的upstream耗时过长超时后，nginx不会尝试将其请求转发为下一个upstream尝试处理后返回，只能直接失败。

那是不是把客户端超时时间调大？或者把nginx upstream超时时间调小解决呢？
调大客户端超时时间当然是不合理的，任何用户请求15s还未收到响应肯定是有问题的，所以正确的做法应该是调小upstream的超时时间，一般来说服务端对于客户端请求处理时间应该都是在数十、数百ms之间，超过1s就已经属于超长请求了，所以不但默认的60s不行，客户端设置的15s也不能用于upstream的超时判定。
最终经过综合考虑服务端各api的耗时情况，先敲定了一个upstream 5s的超时时间配置--由于之前没有经验首次修改步子不迈太大，观察一段时间后继续调整，这样做已经足以很大程度解决以上的3个问题：

• 将用户由于各种原因(如杀app)很快主动断开连接导致的499与nginx达到upstream超时时间时主动结束的504区分开了。

• 504会被纳入max_fails计算，触发nginx摘除失败节点逻辑，在单台机器故障响应缓慢时可以被识别出来暂时摘除出可用节点列表，防止其负载进一步加大并保证后续请求均被正常可用节点处理返回。

• 当nginx等待upstream处理达到5s触发超时时，其会按照uwsgi_next_upstream配置尝试将请求(默认仅限幂等的GET请求)转交给下一个upstream尝试处理后返回，这样在单一upstream由于异常负载较高超时时，其他正常的upstream可以作为backup兜底处理其超时请求，这里客户端原本等待15s超时的请求一般在5~10s内可以兜底返回。

通过proxy_ignore_client_abort配置解决499问题？

在网上查找资料时还有网友提出解除nginx 499问题的一个思路是设置proxy_ignore_client_abort参数，该参数默认为off，将其设置为on 后，对于客户端主动断开请求的情况，nginx会ignore而以upstream实际返回的状态为准，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.

但是在客户端主动断开连接时，设置这个参数的意义除了使nginx log中记录的状态码完全按照upstream返回确定，而非表示客户端断连的499之外，对于实际问题解决完全没有任何帮助，感觉颇有把头埋进沙子的鸵鸟风格，不知道这个参数设置到底会有什么实用的场景。

非高峰時期單一upstream偶發反應緩慢、導致超時的原因

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

以上是nginx配置不當引發的499與failover機制失效問題怎麼解決的詳細內容。更多資訊請關注PHP中文網其他相關文章！