直接查error.log中含ip端口的“is down”或“no live upstreams”日志行，可快速定位故障后端；再结合connect refused、timeout等前置错误及直连验证（telnet/curl），即可区分真宕机与误判。
直接看 Nginx 错误日志（error.log）里带具体 IP 和端口的失败记录，就能快速锁定哪台后端挂了。关键不是等“502”出现后再猜，而是从上游节点被标记为 down 的那一刻开始追溯。
查 upstream 被标记为 down 的日志行
Nginx 主动把某台后端踢出负载池时，一定会在 error.log 里写明。找这类句子：
upstream 192.168.1.10:8080 is down (max_fails=3 fail_timeout=30s)peer 10.0.2.5:3000 cannot be selected: no live upstreams-
no live upstreams while connecting to upstream（说明所有节点都被标 down 了）
只要看到某 IP+端口明确出现在 is down 或 cannot be selected 的日志中，基本就是它——不用再猜。
结合失败原因反向验证真实状态
光看 “is down” 不够，得确认是真挂了，还是误判。顺着同一时间点往前翻 10–30 秒的日志，重点看触发下线的原始错误：
-
connect() failed (111: Connection refused) while connecting to upstream→ 后端进程没启动，或端口没监听 -
upstream timed out (110: Connection timed out) while connecting to upstream→ 网络不通、防火墙拦截、或后端卡死在 accept 阶段 -
upstream prematurely closed connection while reading response header→ 后端程序崩溃、OOM、或响应头都没发完就退出了
每种错误对应一种排查路径，比如 Connection refused 就立刻在 Nginx 机器上执行：nc -zv 192.168.1.10 8080，不通就不用再往下查。
用直连方式交叉验证
别只信 Nginx 日志。在 Nginx 所在服务器上，对疑似故障的后端 IP:PORT 执行两步验证：
- TCP 层通不通：
telnet 192.168.1.10 8080或nc -zv 192.168.1.10 8080 - 应用层是否真能响应：
curl -I http://192.168.1.10:8080/health（或任意轻量接口）
如果 TCP 通但 curl 超时或返回 5xx，说明服务进程活着但已无法处理请求——典型假死，要查后端资源（CPU、内存、数据库连接池、线程阻塞）。
检查健康检查配置是否合理
有时候后端明明正常，却被反复踢出，大概率是 Nginx 健康检查太敏感：
- 默认
max_fails=1，一次超时就下线 → 改成max_fails=3 - 默认
fail_timeout=10s，10 秒内连续失败才标 down → 可设为fail_timeout=30s - 没有启用
proxy_next_upstream error timeout http_502;→ 加上，让失败请求自动切下一节点，避免用户感知
改完记得 nginx -t && nginx -s reload，然后观察日志是否还频繁出现同一节点被 down 的记录。
