max_fails=0会禁用被动健康检查，节点永不摘除，fail_timeout失效；仅适用于本地联调、全链路压测等极少数场景，生产环境应避免，推荐改用max_fails=2 fail_timeout=60s并启用proxy_next_upstream。
设 max_fails=0 确实会禁用 Nginx 的被动健康检查机制，但这个操作不是“提升容错”，而是**完全放弃对后端节点的自动故障识别与隔离能力**。它适用于极少数明确要求“永不跳过任何节点”的场景，比如本地开发联调、全链路压测探针注入、或某些强依赖固定路由的灰度验证环境——但绝不推荐用于生产流量分发。
max_fails=0 的真实效果
当配置为 max_fails=0 时：
- Nginx 彻底忽略所有失败事件（包括连接拒绝、超时、502/503 等），不再维护每个 upstream server 的失败计数器
- 节点永远不会被标记为
down，始终参与轮询，哪怕持续返回 504 或根本连不上 -
fail_timeout参数同时失效，不再起作用 - 即使配了
proxy_next_upstream，失败请求仍会触发重试，但不会导致节点被临时摘除
什么业务真需要 max_fails=0？
真正适合该配置的场景极少，典型包括：
- 后端是单点且必须强保通的内部管理接口（如 K8s apiserver 的反向代理层，仅作透传）
- 做全链路压测时，需确保每台压测 agent 都收到请求，不允许任何节点被“静默跳过”
- 自研服务已内置完备熔断+重试+降级逻辑，Nginx 层只承担纯转发职责，不参与健康决策
替代方案比 max_fails=0 更安全
多数所谓“高容错业务”，其实真正需要的是**降低误判率、延长观察窗口、放宽失败阈值**，而不是彻底关掉健康检查：
- 用
max_fails=2 fail_timeout=60s替代0：允许一次慢响应或偶发错误，60 秒内再失败才摘除，恢复也只需等 60 秒 - 搭配
proxy_next_upstream error timeout http_500 http_502 http_503 http_504：确保业务级错误能参与判断，避免只靠底层连接异常做决策 - 加主动健康检查（
health_check指令）：独立于业务请求周期探测，更可控、更及时
必须同步调整的配套项
若坚持使用 max_fails=0，以下配置必须检查并加固：
-
proxy_next_upstream_tries和proxy_next_upstream_timeout要设合理值（如tries 3; timeout 10s;），否则单个失败请求可能卡住整个连接 -
proxy_connect_timeout、proxy_read_timeout必须显式设置，防止默认值（60s）拖长用户等待 - 务必开启
proxy_buffering off或调大缓冲区，避免因后端无响应导致 Nginx 缓冲积压、OOM
