记一次nginx配置不当引发的499与failover 机制失效

背景

nginx 499在服务端推送流量高峰期长期以来都是存在的，间或还能达到告警阈值触发一小波告警，但主观上一直认为499是客户端主动断开，可能和推送高峰期的用户打开推送后很快杀死app有关，没有进一步探究问题根源。
然而近期在非高峰期也存在499超过告警阈值的偶发情况，多的时候一天几次，少的时候则几天一次，持续一般也就数分钟，并且该类告警一般集中于一台api机器，与推送高峰时多台机器同时499告警明显不同，不由得脑海中升起了问号，经过和小伙伴的共同探究，最后发现之前对于499是客户端主动断开因而和服务端关系不大的想当然认知是错误的，这里记录一下。

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 fault 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基本上长期位于告警阈