nginx 502

nginx报错 502 no live upstreams while connecting to upstream
nginx 跟后端创建了大量的连接。没有使用http1.1长连接导致的（默认是http1.0短连接）。
解决方案：在upstream中添加keepalive配置

upstream stream_name{
    server host:port;
    server host:port;

    keepalive 256;
}
location {
...
proxy_http_version 1.1;
proxy_set_header Connection "";
...
}

默认情况下 Nginx 访问后端都是用的短连接(HTTP1.0)，一个请求来了，Nginx 新开一个端口和后端建立连接，请求结束连接回收。如果配置了http 1.1长连接，那么Nginx会以长连接保持后端的连接，如果并发请求超过了 keepalive 指定的最大连接数，Nginx 会启动新的连接来转发请求，新连接在请求完毕后关闭，而且新建立的连接是长连接。
nginx1.1.4版本开始支持长连接
同一网段不经过防火墙，不会对长连接状态进行干预；不同网段(生产上)一般都有防火墙,,会对连接状态进行重置
生产上防火墙连接要确认是长连接还是短连接，如果要开通长连接要有链接探测机制，释放无效链接，以免影响防火墙性能。
如果含有Tomcat的话也需要配置server.xml Connector

keepAliveTimeout="60000"
maxKeepAliveRequests="1000000"

Nginx 与后端机器的通信效率更高，后端机器的负担更低。
netstat -n | grep TIME_WAIT

nginx配置了proxy_next_upstream属性，这个属性作用是如果发现请求返回的是后面的配置状态时就会转发到下一个upstream

测试发现，如果每个实例都返回500后，接下来的请求就会出现502，如果访问正常的api，又会恢复正常，说明nginx当发现upstream都为500的时候，就会临时disable所有upstream，也就是上面error.log上出现的“upstream server temporarily disabled”，后续请求就会有“no live upstreams”问题，但是出现502后，新请求会重新检测，当请求是200，就会恢复正常。

解决：问题原因找到了，解决办法也就简单了，这个500一般是服务器端的bug，一般请求都不会直接返回500，出现问题及时解决就好，另外这个使用这个属性时得注意，如果请求是后面枚举的状态时，nginx会直接转到另外一个upstream，所以会出现多个实例都接收到请求的情况，有些情况下是不允许的，所以使用的时候需要分析一下。

原文链接：https://blog.csdn.net/piaohai/article/details/102753168
下面还有一个参数影响重试次数，0表示不限制。：

Syntax: proxy_next_upstream_tries number;
Default: proxy_next_upstream_tries 0;
Context: http, server, location

原文链接：https://blog.csdn.net/christ1208/article/details/106949000/

Nginx默认判断失败节点状态以connect refuse和timeout状态为准，不以HTTP错误状态进行判断失败，

HTTP只要能返回状态说明该节点还可以正常连接，所以nginx判断其还是存活状态除非添加了proxy_next_upstream指令设置对404、502、503、504、500和time out等错误转到备机处理，
nginx记录错误数量只记录timeout 、connect refuse、502、500、503、504这6种状态，timeout和connect refuse是永远被记录错误状态，而502、500、503、504只有在配置proxy_next_upstream参数之后nginx才会记录这4种HTTP错误到fails中；
https://blog.csdn.net/weixin_30621711/article/details/96625770

https://blog.csdn.net/my201110lc/article/details/108245658

另外
proxy_next_upstream error timeout http_500 non_idempotent;
non_idemponent ，Nginx 默认对 non-idempotent 请求，比如 POST /LOCK/PATCH，是不进行重试。常见的情况就是 POST 请求出错后不会重试，需要加上该设置。
官方文档的说明是：
normally, requests with a non-idempotent method (POST, LOCK, PATCH) are not passed to the next server if a request has been sent to an upstream server (1.9.13); enabling this option explicitly allows retrying such requests;
意思是如果不加上non_idempotent，对POST这些不幂等的方法，出错是不会重试的。