Nginx 中健康检查如何排查所有后端挂掉时触发的 502 错误

“no live upstreams”表明Nginx因健康检查连续失败将所有上游节点标记为不可用，并非必然全宕；需直连验证后端真实状态、核查max_fails/fail_timeout等激进配置、排查网络丢包或连接限制等底层阻塞点。

当 Nginx 报“502 Bad Gateway”且日志显示 “no live upstreams”，说明它已将 upstream 中所有节点标记为不可用——这不是个别故障，而是健康检查机制判定整个集群“失联”。排查重点不是“后端是否真挂了”，而是“Nginx 为什么认为它们都挂了”。

确认是误判下线，还是真实全宕

别急着重启，先绕过 Nginx 直连验证：

1. 对每个后端节点执行 curl -I http://IP:PORT/health 或主接口（如 /），看能否拿到 HTTP 200 响应
2. 登录每台节点，运行 ss -tlnp | grep :PORT，确认端口确实在监听，且对应进程未僵死或被 OOM 杀掉
3. 查 Nginx error.log：高频出现 connect() failed (111: Connection refused) → 后端进程没起来；高频 Connection timed out → 更可能是网络、防火墙或连接队列满

检查健康检查配置是否过于激进

“no live upstreams” 多数由被动检查参数太敏感导致，一次抖动就永久剔除：

1. 检查 upstream 块中 max_fails 和 fail_timeout：例如 max_fails=1 fail_timeout=60s 意味着只要失败 1 次，该节点 60 秒内完全不参与调度
2. 若启用了主动健康检查（如 health_check 指令），确认其 interval、fails、passes 是否合理，避免因探测超时或路径返回非 2xx 被误判
3. proxy_next_upstream error timeout http_500 等指令只影响单次请求重试，不改变节点存活状态，不能替代健康检查逻辑

排查连接建立阶段的隐性阻塞

后端活着，但 Nginx 就是连不上，也会反复触发失败并下线节点：

1. 在 Nginx 机器上执行 netstat -s | grep -i "retransmit|drop"，高重传率说明网络丢包，可能让健康探测包丢失
2. 检查后端节点是否开启 SYN cookies 且 tcp_max_syn_backlog 过小：sysctl net.ipv4.tcp_syncookies 为 1 且 backlog 不足时，会直接返回 RST，表现为 Connection refused
3. 确认 Nginx worker 的文件描述符限制：ulimit -n 若远低于并发连接需求，会出现 accept() failed (24: Too many open files)，间接导致 upstream 连接失败

验证 DNS、SNI 等隐性依赖是否正常

upstream 使用域名或 HTTPS 时，解析或握手失败也会被归为“无存活节点”：

1. 若 upstream 定义为 server api.example.com:443，需在 Nginx 机器执行 getent hosts api.example.com，确保 DNS 解析稳定
2. HTTPS upstream 必须加 proxy_ssl_server_name on 和 proxy_ssl_name api.example.com，否则 SNI 握手失败，连接直接中断
3. 检查系统时间是否严重偏差（尤其 TLS 场景），证书有效期校验失败也会静默断连