Nginx_502

Nginx开启的前提下：

Nginx 502就是后端对请求无法处理，

查看监控后端几个API的负载均很低，当前请求的QPS远远低于服务的上限。
一、（有可能是负载均衡问题导致服务器挂掉了）通过监控。查看QPS数量

而且同一瞬间，多套独立部署的API均处理不过来的概率也比较低。

我们简单做了个对比测试，分别对域名（请求走Nginx）与直接通过IP对内网一个API通过wrk进行小规模压测

直接通过域名走Nginx对API进行压测的话，QPS远远小于预期，并且存在大量失败请求。基本断定问题出在Nginx —> API 这条链路上。同时排除了后端服务响应不过来的可能性。网络问题可能性大一点。

二、对nginx转发和直接访问两种方式进行压测

一开始我们怀疑云服务商对内网带宽做了限制，我们观察内网带宽达到在200MB/S后就上不去了，所以我们在Nginx机器上ping后端服务，观察一段时间发现有小量抖动，但基本延迟正常。那云服务商对网络做限制的可能性就变小了很多。

三、怀疑nginx转发的带宽受到限制，用nginx来ping后端查看延迟

四、查看nginx错误日志

观察Nginx错误日志:

2021/09/26 14:23:00 [error] 4950#4950: *4162133210 no live upstreams while connecting to upstream, client: xxx.xxx.xxx.xxx, server: api.xx.xxxxxxx.cn, request: "POST /xx/xxxxxx/bidder HTTP/1.1", upstream: "http://xxxxxxxxxx/bidder", host: "api.xx.xxxxxxx.cn"

这里出现no live upstreams while connecting to upstream, 也就说一瞬间Nginx检测不到任何存活的后端服务，而网络又没有大波动，那就可能是TCP链接出问题。打开Zabbix监控发现TCP连接数的确发生剧烈的波动现象。

五、锁定是TCP连接的问题

这时候问题很明显，Nginx->API这一链路存在大量的TCP链接被回收的情况，我们马上在API机器上查看链接状态

 

 

原因：
记一次生产环境Nginx间歇性502的事故分析过程 - 简书

 

但整个事故中，仍然存在几个疑点:

1. 为什么Nginx转发的流量中，会混入1.0协议的请求呢？
2. 是什么原因导致Nginx或Nginx所在服务器的操作系统在对TCP链接大量回收，并且把正常连接也回收掉导致后端Server "no live upstreams"了呢？

https://www.jianshu.com/p/0843be9d8d35