max_fails是Nginx被动健康检查中与fail_timeout联动的关键参数，用于在指定时间窗口内累计失败次数后临时摘除节点；例如max_fails=2 fail_timeout=10s表示10秒内连续2次失败即停用该节点10秒。
max_fails 不是“设个数字就完事”的参数，它直接决定 Nginx 何时把缓存后端（比如 Redis、Memcached 或自建缓存服务）标记为宕机，进而影响故障感知速度和切换稳定性。调得太松，故障节点持续收请求，拖垮整体响应；调得太紧，网络抖动就误判下线，造成不必要的流量震荡。
理解 max_fails 和 fail_timeout 的联动逻辑
max_fails 必须和 fail_timeout 配合使用才有效——它不是统计“总失败次数”，而是指在 fail_timeout 规定的时间窗口内，连续失败达到 max_fails 次，该 server 才被标记为不可用。之后 Nginx 会在接下来的 fail_timeout 秒内跳过它，到期自动重试探测。
- 例如 max_fails=2 fail_timeout=15s：15 秒内连续 2 次健康检查或代理请求失败 → 标记宕机 → 接下来 15 秒不转发，第 16 秒起尝试恢复连接
- 若只写 max_fails=2 但没配 fail_timeout，Nginx 会用默认值 10 秒，容易在高并发下误剔除
- 缓存后端通常响应快（毫秒级），所以失败更可能是真故障而非慢响应，适合比应用后端更敏感的设置
缓存后端场景下的推荐取值
针对 Redis、Memcached 等轻量、低延迟的缓存服务，建议以“快速发现 + 安全恢复”为目标调整：
- 基础稳定型：max_fails=3 fail_timeout=30s —— 适合跨机房部署或偶有网络延迟的环境，避免因瞬时丢包误判
- 高敏探测型：max_fails=2 fail_timeout=10s —— 适用于同机房、内网直连的 Redis 集群，能更快切走流量，但需确保客户端有重试机制
- 强一致性要求：搭配主动健康检查（如 OpenResty 的 health_check），用 interval=3s fails=2 timeout=1s，让探测更贴近缓存服务真实状态
必须同步配置的关键配套项
单调 max_fails 很难生效，以下三项必须一起检查：
- proxy_read_timeout 要小于 fail_timeout：比如 fail_timeout=10s，proxy_read_timeout 最好设为 3–5s，否则请求卡在读阶段超时，无法及时触发失败计数
- 禁用 proxy_next_upstream http_502（除非你真需要）：缓存服务返回 502 多因进程崩溃，应直接剔除，而不是反复重试其他节点
- 后端需提供 /health 接口并返回 200：如果用了主动健康检查，/health 必须真实反映缓存连接性（例如 PHP 中用 Redis::ping()），不能只是进程存活
验证与观察要点
上线后别只看日志有没有 “upstream timed out”，重点确认三件事：
- 用 nginx -T | grep -A5 "upstream.*cache" 检查配置是否加载成功，参数是否拼写正确（注意空格和分号）
- 手动模拟缓存节点宕机（如 systemctl stop redis），观察 access.log 中对应 IP 是否在 fail_timeout 内彻底消失
- 查看 Nginx 状态页（需启用 stub_status）或用 openresty/lua-resty-healthcheck 模块输出实时节点状态，确认“down”标记是否准确生效
