Nginx开源版被动健康检查需同时配置max_fails、fail_timeout和proxy_next_upstream三要素，并配合超时控制与业务调优；节点被标记为down后靠真实请求试探自动恢复，定时探活需依赖第三方模块。
直接靠真实请求失败来标记节点不可用，是 Nginx 开源版最常用也最稳妥的方式。它不依赖额外模块，但必须把几个关键参数配齐、配对，否则健康检查形同虚设。
被动检查三要素必须同时生效
不是设一个参数就起作用，而是三个配置协同工作：
- 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;，明确告诉 Nginx 哪些响应才算“失败”，才会触发计数和重试 - 不能漏掉超时控制：默认
proxy_read_timeout是 60 秒，若后端卡住但没断连，单次请求会堵满 1 分钟。建议显式设为更短值，比如proxy_read_timeout 3s;，再配合proxy_next_upstream_timeout 3s;，确保失败能快速判定、及时重试
按业务类型调优失败阈值
统一用 max_fails=3 fail_timeout=30s 容易误判或响应滞后，应结合后端行为调整：
-
高 QPS 网关（如 API 入口）：设
max_fails=15 fail_timeout=10s，扩大容错次数、缩短统计窗口，避免毛刺导致频繁剔除 -
慢操作服务（如报表导出）：改用
max_fails=2 fail_timeout=60s，防止一次长耗时请求被误判为故障 -
强一致链路（如支付回调）：用
max_fails=1 fail_timeout=10s，首次失败即隔离，宁可保守也不冒险
自动恢复靠真实流量驱动
被标记为 down 的节点不会静默等待，而是在下一个新请求到达时，主动发一次试探请求：
- 如果试探成功（返回正常响应且未超时），立即恢复其可用状态，后续请求照常分发
- 如果试探失败，则继续保持 down 状态，等下一次请求到来再试
- 这意味着恢复是即时的、无固定周期的，但依赖真实流量——低峰期可能延迟发现恢复
想真正定时探活？得加模块
开源 Nginx 默认不支持主动发心跳，health_check 指令仅限 NGINX Plus 商业版。若需定时 HTTP 探测（如 GET /health），必须引入第三方模块：
- 常见选择是 nginx_upstream_check_module，需从源码编译 Nginx 并加载
- 配置中要加
check interval=3 rise=2 fall=5 type=http，并指定探测路径与期望响应码 - 务必设置
default_down=true，防止 Nginx 启动时把未就绪节点当健康节点用 - 探测路径建议用独立健康端点（如
/actuator/health），且确保该路径在防火墙白名单中放行
