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