“no live upstreams”表明Nginx因健康检查连续失败将所有上游节点标记为不可用，并非必然全宕；需直连验证后端真实状态、核查max_fails/fail_timeout等激进配置、排查网络丢包或连接限制等底层阻塞点。
当 Nginx 报“502 Bad Gateway”且日志显示 “no live upstreams”，说明它已将 upstream 中所有节点标记为不可用——这不是个别故障，而是健康检查机制判定整个集群“失联”。排查重点不是“后端是否真挂了”，而是“Nginx 为什么认为它们都挂了”。
确认是误判下线，还是真实全宕
别急着重启，先绕过 Nginx 直连验证：
- 对每个后端节点执行
curl -I http://IP:PORT/health或主接口（如/），看能否拿到 HTTP 200 响应 - 登录每台节点，运行
ss -tlnp | grep :PORT，确认端口确实在监听，且对应进程未僵死或被 OOM 杀掉 - 查 Nginx error.log：高频出现
connect() failed (111: Connection refused)→ 后端进程没起来；高频Connection timed out→ 更可能是网络、防火墙或连接队列满
检查健康检查配置是否过于激进
“no live upstreams” 多数由被动检查参数太敏感导致，一次抖动就永久剔除：
- 检查
upstream块中max_fails和fail_timeout：例如max_fails=1 fail_timeout=60s意味着只要失败 1 次，该节点 60 秒内完全不参与调度 - 若启用了主动健康检查（如
health_check指令），确认其interval、fails、passes是否合理，避免因探测超时或路径返回非 2xx 被误判 -
proxy_next_upstream error timeout http_500等指令只影响单次请求重试，不改变节点存活状态，不能替代健康检查逻辑
排查连接建立阶段的隐性阻塞
后端活着，但 Nginx 就是连不上，也会反复触发失败并下线节点：
- 在 Nginx 机器上执行
netstat -s | grep -i "retransmit\|drop"，高重传率说明网络丢包，可能让健康探测包丢失 - 检查后端节点是否开启 SYN cookies 且
tcp_max_syn_backlog过小：sysctl net.ipv4.tcp_syncookies为 1 且 backlog 不足时，会直接返回 RST，表现为 Connection refused - 确认 Nginx worker 的文件描述符限制：
ulimit -n若远低于并发连接需求，会出现accept() failed (24: Too many open files)，间接导致 upstream 连接失败
验证 DNS、SNI 等隐性依赖是否正常
upstream 使用域名或 HTTPS 时，解析或握手失败也会被归为“无存活节点”：
- 若
upstream定义为server api.example.com:443，需在 Nginx 机器执行getent hosts api.example.com，确保 DNS 解析稳定 - HTTPS upstream 必须加
proxy_ssl_server_name on和proxy_ssl_name api.example.com，否则 SNI 握手失败，连接直接中断 - 检查系统时间是否严重偏差（尤其 TLS 场景），证书有效期校验失败也会静默断连
