nginx负载均衡的自动故障恢复依赖max_fails与fail_timeout绑定的被动健康检查机制：在fail_timeout滑动窗口内累计失败max_fails次即摘除节点，超时后由首个请求试探恢复；需同步配置proxy_next_upstream、超时对齐及重试限制。
Nginx 的负载均衡本身不提供“自动故障恢复”或“智能健康探测”能力，它的容错逻辑依赖于显式配置的参数和被动探测机制，核心是通过失败计数与超时判断来临时摘除异常节点。
fail_timeout 与 max_fails 控制节点摘除与恢复
这是 Nginx 被动健康检查的核心机制。当某台后端服务器在 fail_timeout 时间窗口内连续失败 max_fails 次（默认 1），Nginx 就会将其标记为不可用，并在 fail_timeout 时长内不再转发请求过去。
- 失败判定依据：连接拒绝（connection refused）、超时（timeout）、返回 5xx 状态码（仅限 proxy_next_upstream 中启用 http_500、http_502 等）
- 恢复逻辑：不是定时轮询检测，而是等 fail_timeout 过期后，下一次请求会尝试重新连接；若成功，则重置失败计数；若仍失败，重新进入禁用周期
- 典型配置：
server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;表示 30 秒内失败 3 次就剔除，30 秒后首次请求试探恢复
proxy_next_upstream 决定什么情况下切换节点
该指令定义了在何种响应条件下允许 Nginx 主动重试下一个 upstream server，是容错行为的“触发开关”。它不决定是否剔除节点，而是决定当前请求能否被转发到其他节点。
- 常用值：
error timeout http_500 http_502 http_503 http_504 - error：连接上游失败（如 connect() 失败）
- timeout：代理过程超时（proxy_read_timeout / proxy_connect_timeout 触发）
- HTTP 状态码需配合
proxy_intercept_errors on;才能生效（否则 5xx 直接返回给客户端） - 注意：它只影响单次请求的重试行为，不影响节点长期可用性状态
keepalive 与 connection reuse 对容错的影响
启用 upstream keepalive（如 keepalive 32;）可复用后端连接，但若复用的连接已断开或卡死，可能掩盖真实故障，导致请求 hang 住或超时——此时仍依赖 proxy_read_timeout 和 proxy_next_upstream 触发重试。
- 建议搭配设置合理的
proxy_read_timeout（如 10s），避免因长连接假死阻塞整个请求链路 - keepalive 不改变节点健康状态判定逻辑，只是优化连接效率
- 若后端进程崩溃但 TCP 连接未及时关闭（TIME_WAIT 或半开连接），可能造成短暂误判，需靠超时+重试兜底
主动健康检查需借助第三方模块或外部方案
开源版 Nginx 官方不支持主动心跳探测（如定期发 HTTP HEAD 请求校验），必须通过扩展实现：
-
nginx-plus：商业版内置
health_check指令，支持 interval、fails、passes、match 等精细控制 - nginx_upstream_check_module：开源第三方模块，可编译进 Nginx，提供 TCP/HTTP 主动探活
- 外部监控 + 动态配置：如 Consul + nginx-upsync-module，由服务发现系统实时推送健康节点列表
- 纯 OpenResty 场景可结合 lua-resty-healthcheck 库，在 Lua 层实现自定义探测逻辑
不复杂但容易忽略：容错效果高度依赖 超时时间匹配业务实际 和 max_fails/fail_timeout 的合理组合，而非单纯堆叠参数。
