直接配置max_fails、fail_timeout和proxy_next_upstream即可启用原生被动健康检查，三者必须协同生效：upstream中为server设置max_fails与fail_timeout定义滑动窗口失败阈值，location中通过proxy_next_upstream显式指定错误类型触发重试与计数，并需配合超时参数确保快速判定。
直接配置 max_fails、fail_timeout 和 proxy_next_upstream 就能启用被动式健康检查，它不依赖额外模块，靠真实请求失败来触发剔除，适合大多数生产场景。
基础三要素必须同时生效
被动检查不是“设一个参数就起作用”，而是三个配置协同工作：
-
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 哪些响应算“失败”，才会计入max_fails计数。 -
不能漏掉超时控制：默认
proxy_read_timeout是 60 秒，若后端卡住但没断连，单次请求会堵满 1 分钟。建议显式设为更短值，比如proxy_read_timeout 3s;，配合proxy_next_upstream_timeout 3s;，确保失败能快速判定和重试。
按业务特征调优失败阈值
统一用 max_fails=3 fail_timeout=30s 容易误判或延迟响应。应结合后端行为调整：
- 常规 Web 接口（如用户登录）：保持
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 的节点不会静默等待，而是“按需试探”：
- Nginx 不定时轮询，而是在下一个新请求到达时，**主动发一次试探请求**到该节点。
- 如果试探成功（返回正常响应且未超时），立即恢复其可用状态，后续请求照常分发。
- 如果试探失败，则继续保持 down 状态，再等下一次请求到来时重试。
- 这意味着恢复是即时的、无固定周期的，但依赖真实流量驱动——低峰期可能延迟发现恢复。
常见陷阱与规避方式
很多被动检查“看似配置了却无效”，往往卡在这几个细节上：
-
没启用
proxy_next_upstream：即使后端返回 502，Nginx 也只返回错误给客户端，不重试、不计数、不剔除。 -
混用了
http_404或invalid_header：404 多数是业务逻辑返回，不代表后端宕机；加进去会导致健康检查过度敏感。 -
后端启动慢但端口已监听：Nginx 启动时会把未就绪节点当健康节点用，初期流量全打过去。可在应用层加 readiness probe，或配合
backup节点过渡。 -
未设
proxy_next_upstream_tries：默认只重试 1 次，若集群只有两个节点，失败后可能无备选。建议设为proxy_next_upstream_tries 3;提升容错弹性。
