Nginx需通过显式配置实现快速故障发现与自动规避：设max_fails为2–3、fail_timeout为15–30秒；启用proxy_next_upstream重试机制并限次限时；配合短connect_timeout、limit_conn及upstream keepalive；最后配置backup节点兜底。
轮询本身不感知后端是否真正可用，节点突然下线会导致部分请求失败、超时甚至堆积。要减轻影响，关键不是“避免下线”，而是让 Nginx 快速发现、自动规避、有限重试、并留有兜底。
主动剔除失效节点
仅靠默认轮询，Nginx 会在首次连接失败后才尝试下一个节点，期间用户已感知错误。必须显式配置故障判定机制：
- max_fails 设为 2–3：连续失败 2 次就标记节点为不可用，比默认值（1 次）更敏感
- fail_timeout 设为 15–30 秒：既不过早恢复（避免反复试探），也不长期隔离（保障快速回归）
- 每个 server 行单独设置，不依赖全局默认值
请求失败后自动换节点重试
单次请求打到已下线节点时，不能直接返回 502，而应尝试其他健康节点：
- 启用 proxy_next_upstream，明确指定触发重试的条件：error timeout http_500 http_502 http_503 http_504
- 用 proxy_next_upstream_tries 限制最多重试 2–3 次，防止无限循环或跨节点雪崩
- 搭配 proxy_next_upstream_timeout（如 5s），确保重试总耗时不失控
连接层提前规避风险
TCP 层连不通只是下线的一种表现，还有可能节点活着但应用卡死、线程耗尽。这时需结合连接控制：
- 设置较短的 proxy_connect_timeout（2–3s），避免长时间等待建连
- 用 limit_conn 限制发往每个后端地址的并发连接数，防止单点被突发连接压垮
- 启用 upstream 级 keepalive（如 keepalive 32），复用连接减少建连失败概率
提供基础服务能力兜底
当所有主节点都因下线或故障不可用时，仍需保障最低可用性：
- 在 upstream 中定义 backup 节点，仅在全部主节点失效时启用
- backup 节点可指向降级服务、静态页面或维护提示页，避免全站 502
- 不建议把 backup 当主力用，它只为极端场景争取修复时间
