nginx報(bào)錯(cuò) 502 no live upstreams while connecting to upstream
nginx 跟后端創(chuàng)建了大量的連接棠隐。沒有使用http1.1長(zhǎng)連接導(dǎo)致的（默認(rèn)是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 "";
...
}
默認(rèn)情況下 Nginx 訪問后端都是用的短連接(HTTP1.0)藐窄，一個(gè)請(qǐng)求來(lái)了贮泞，Nginx 新開一個(gè)端口和后端建立連接楞慈，請(qǐng)求結(jié)束連接回收。如果配置了http 1.1長(zhǎng)連接啃擦，那么Nginx會(huì)以長(zhǎng)連接保持后端的連接囊蓝，如果并發(fā)請(qǐng)求超過(guò)了 keepalive 指定的最大連接數(shù)，Nginx 會(huì)啟動(dòng)新的連接來(lái)轉(zhuǎn)發(fā)請(qǐng)求令蛉，新連接在請(qǐng)求完畢后關(guān)閉聚霜，而且新建立的連接是長(zhǎng)連接狡恬。
nginx1.1.4版本開始支持長(zhǎng)連接
同一網(wǎng)段不經(jīng)過(guò)防火墻，不會(huì)對(duì)長(zhǎng)連接狀態(tài)進(jìn)行干預(yù)蝎宇；不同網(wǎng)段(生產(chǎn)上)一般都有防火墻,,會(huì)對(duì)連接狀態(tài)進(jìn)行重置
生產(chǎn)上防火墻連接要確認(rèn)是長(zhǎng)連接還是短連接弟劲，如果要開通長(zhǎng)連接要有鏈接探測(cè)機(jī)制，釋放無(wú)效鏈接姥芥，以免影響防火墻性能兔乞。
如果含有Tomcat的話也需要配置server.xml Connector
keepAliveTimeout="60000"
maxKeepAliveRequests="1000000"
Nginx 與后端機(jī)器的通信效率更高，后端機(jī)器的負(fù)擔(dān)更低凉唐。
netstat -n | grep TIME_WAIT
nginx配置了proxy_next_upstream屬性庸追，這個(gè)屬性作用是如果發(fā)現(xiàn)請(qǐng)求返回的是后面的配置狀態(tài)時(shí)就會(huì)轉(zhuǎn)發(fā)到下一個(gè)upstream
測(cè)試發(fā)現(xiàn)，如果每個(gè)實(shí)例都返回500后台囱，接下來(lái)的請(qǐng)求就會(huì)出現(xiàn)502锚国，如果訪問正常的api，又會(huì)恢復(fù)正常玄坦，說(shuō)明nginx當(dāng)發(fā)現(xiàn)upstream都為500的時(shí)候血筑，就會(huì)臨時(shí)disable所有upstream，也就是上面error.log上出現(xiàn)的“upstream server temporarily disabled”煎楣，后續(xù)請(qǐng)求就會(huì)有“no live upstreams”問題豺总，但是出現(xiàn)502后，新請(qǐng)求會(huì)重新檢測(cè)择懂，當(dāng)請(qǐng)求是200喻喳，就會(huì)恢復(fù)正常。
解決：?jiǎn)栴}原因找到了困曙，解決辦法也就簡(jiǎn)單了表伦，這個(gè)500一般是服務(wù)器端的bug，一般請(qǐng)求都不會(huì)直接返回500慷丽，出現(xiàn)問題及時(shí)解決就好蹦哼，另外這個(gè)使用這個(gè)屬性時(shí)得注意，如果請(qǐng)求是后面枚舉的狀態(tài)時(shí)要糊，nginx會(huì)直接轉(zhuǎn)到另外一個(gè)upstream纲熏，所以會(huì)出現(xiàn)多個(gè)實(shí)例都接收到請(qǐng)求的情況，有些情況下是不允許的锄俄，所以使用的時(shí)候需要分析一下局劲。
原文鏈接：https://blog.csdn.net/piaohai/article/details/102753168
下面還有一個(gè)參數(shù)影響重試次數(shù)，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默認(rèn)判斷失敗節(jié)點(diǎn)狀態(tài)以connect refuse和timeout狀態(tài)為準(zhǔn)鱼填，不以HTTP錯(cuò)誤狀態(tài)進(jìn)行判斷失敗，
HTTP只要能返回狀態(tài)說(shuō)明該節(jié)點(diǎn)還可以正常連接毅戈，所以nginx判斷其還是存活狀態(tài)除非添加了proxy_next_upstream指令設(shè)置對(duì)404苹丸、502塑猖、503、504谈跛、500和time out等錯(cuò)誤轉(zhuǎn)到備機(jī)處理羊苟，
nginx記錄錯(cuò)誤數(shù)量只記錄timeout 、connect refuse感憾、502蜡励、500、503阻桅、504這6種狀態(tài)凉倚，timeout和connect refuse是永遠(yuǎn)被記錄錯(cuò)誤狀態(tài)，而502嫂沉、500稽寒、503、504只有在配置proxy_next_upstream參數(shù)之后nginx才會(huì)記錄這4種HTTP錯(cuò)誤到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 默認(rèn)對(duì) non-idempotent 請(qǐng)求，比如 POST /LOCK/PATCH蚓土，是不進(jìn)行重試宏侍。常見的情況就是 POST 請(qǐng)求出錯(cuò)后不會(huì)重試，需要加上該設(shè)置蜀漆。
官方文檔的說(shuō)明是：
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谅河，對(duì)POST這些不冪等的方法，出錯(cuò)是不會(huì)重試的确丢。
