应直连验证后端真实响应能力、分析nginx错误日志定位失效节点、复核upstream健康检查配置合理性，并排查系统级连接限制，避免仅依赖nginx“主观判断”。
检查 upstream 存活状态不能只看 Nginx 是否“认为它活着”，而要验证后端节点是否真能响应请求、系统是否撑得住、配置是否让健康检查合理生效。关键在于绕过 Nginx，直连验证 + 日志佐证 + 配置复核。
查 Nginx 错误日志，定位具体失效节点
打开 /var/log/nginx/error.log，搜索 upstream 或 no live upstreams：
- 出现 connect() failed (111: Connection refused) → 对应 IP:端口的服务没启动、端口错、监听地址写成 127.0.0.1（仅本机可连）、防火墙拦截；
- 出现 upstream timed out 或 prematurely closed connection → 连得上但处理失败，可能是进程卡死、线程池满、OOM 被杀、accept 队列溢出；
- 出现 no live upstreams → 所有节点都被标记为不可用，大概率是健康检查参数太激进或网络层持续阻塞。
绕过 Nginx 直连后端，验证真实响应能力
登录疑似故障的服务器，用本地回环地址测试：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- 执行 curl -I http://127.0.0.1:8080/health（替换为实际端口和健康路径），必须返回 HTTP 200 且响应时间在 1–2 秒内；
- 运行 ss -tlnp | grep :8080，确认端口确实在 LISTEN 状态，并显示对应进程 PID；
- 检查后端自身日志（如 Tomcat catalina.out、PHP-FPM log），搜 OOM killed、too many open files、max children reached 等线索。
核对 upstream 健康检查配置是否合理
存活判定依赖配置逻辑，不是“服务开着就自动算活”：
- 确认 upstream 块中每个 server 行都带 max_fails=2 fail_timeout=30s（或类似宽松值），否则一次失败就剔除，抖动即熔断；
- 若用了 health_check 指令（需 Plus 或 Stream 模块），检查 interval、fails、passes 是否与业务容忍度匹配；
- 避免 max_fails=1 或 fail_timeout 过长（如 600s），这会导致节点长期失联却无法恢复。
排查底层连接建立是否被系统级限制阻断
即使服务活着，Nginx 也可能连不上：
- 在 Nginx 机器执行 netstat -s | grep -i "retransmit\|drop"，重传率高说明网络丢包；
- 在后端节点检查 sysctl net.ipv4.tcp_max_syn_backlog 和 tcp_syncookies，过小会直接拒绝新连接；
- 确认 Nginx worker 的文件描述符限制：ulimit -n 至少设为 65535，否则并发高时出现 Too many open files 导致 upstream 连接失败。
