nginx轮询默认不自动剔除宕机后端，需配置max_fails、fail_timeout、proxy_next_upstream及超时参数才能实现故障感知与恢复；低流量场景应补充主动健康检查。
Nginx 轮询本身不会自动识别后端是否宕机，所谓“自动剔除”是默认行为的误解。真实情况是：不加任何健康检查配置时，Nginx 会照常把请求发给已宕机的节点，直到超时返回 502/504，下次还继续试——根本不会剔除。
必须配齐三个被动检查要素
要让轮询具备故障感知能力，需 upstream 和 location 两处协同生效：
-
upstream 中每个 server 必须带 max_fails 和 fail_timeout：例如
server 10.0.1.10:8080 max_fails=3 fail_timeout=30s;。表示 30 秒内连续失败 3 次，该节点被标记为 down，暂停服务 30 秒。 -
location 中启用 proxy_next_upstream：仅写
proxy_pass不够。要明确指定哪些错误触发重试和计数，推荐：proxy_next_upstream error timeout http_500 http_502 http_503 http_504; -
显式设置超时参数：避免默认 60 秒 read timeout 拖慢判定。建议统一设为较短值，如：
proxy_connect_timeout 5s; proxy_send_timeout 10s; proxy_read_timeout 10s;
被标记为 down 的节点如何恢复
不是靠定时心跳，而是“请求试探”机制：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- 下一个真实请求到达时，Nginx 会向该 down 节点发一次试探请求；
- 若连接成功、响应正常、未超时 → 立即恢复为可用状态；
- 若试探失败 → 继续保持 down，等待下一次请求再来；
- 当所有主节点都 down 时，Nginx 会强制重试全部节点（包括 down 的），此时若某台已恢复，就能立刻承接流量。
低流量或关键业务需额外补位
被动检查依赖真实请求，在凌晨或调用量低时可能几十秒无试探，恢复滞后：
- 对支付、订单等强一致链路，建议搭配
nginx_upstream_check_module做主动探活（OpenResty 已内置，原生 Nginx 需编译）； - 在 upstream 块中添加类似
check interval=3000 rise=2 fall=2 timeout=1000 type=http uri=/health;； - 确保后端提供轻量、稳定、快速响应的
/health接口（HTTP 200，耗时 ≤200ms）； - 避免用
/或数据库查询类接口做探针，否则会放大故障风险。
验证是否真正生效
别只看配置，动手验证更可靠：
- 手动停掉一台后端服务，观察 Nginx error log 是否出现
upstream failed或no live upstreams类报错； - 确认后续请求不再打到该节点（可用 tcpdump 或后端 access log 验证）；
- 重启该服务后，用
curl -I http://nginx-ip/status（若启用了check_status）查看状态是否变回up； - 用
curl -v --connect-timeout 1 http://backend快速模拟单次失败，观察是否计入 max_fails 计数。
