nginx支持后端节点故障恢复后的自动重入调度，需正确配置被动或主动健康检查：被动检查依赖max_fails/fail_timeout与proxy_next_upstream触发试探请求；主动检查需nginx_upstream_check_module实现周期探活，并配合后端就绪接口与网络放行。
Nginx 默认支持后端节点故障恢复后的自动重新纳入调度，但必须正确配置健康检查参数，否则节点可能长期“离线”不被重试。关键在于让 Nginx 明确知道：什么时候算“已恢复”，以及“多久后重试”。
被动检查场景：靠请求失败触发摘除，靠时间窗口自动试探恢复
这是开源 Nginx 原生能力，无需额外模块，依赖 proxy_next_upstream 和 upstream 中的 max_fails/fail_timeout：
-
每个 server 行必须显式设置：
max_fails=3 fail_timeout=30s（示例值），表示连续失败 3 次后，该节点在 30 秒内不参与调度 - 30 秒到期后，Nginx 会自动发起一次试探性请求；若成功，立即重新标记为可用，后续流量正常进入
-
location 中需启用重试逻辑：
proxy_next_upstream error timeout http_500 http_502 http_503 http_504，确保失败能触发切换 - 注意：没有请求打过去时，不会主动探测；所以恢复后首次请求可能略慢（要等试探请求完成）
主动检查场景：定时探活 + 状态判定，恢复更及时可靠
使用 nginx_upstream_check_module（常见于 OpenResty 或手动编译版本），可实现真正意义上的周期性健康探测：
- 在 upstream 块中添加
check指令，例如：check interval=3 rise=2 fall=5 type=http - rise=2 表示连续 2 次探测成功，才将节点从“不可用”状态升为“可用”
- fall=5 表示连续 5 次失败才降级，避免网络抖动误判
- 搭配
check_http_expect_alive http_2xx http_3xx，只认 2xx/3xx 为健康，排除临时 503 等响应 - 务必设
default_down=true，防止 Nginx 启动时把未就绪节点当健康节点用
后端服务自身需配合就绪信号
仅靠 Nginx 配置还不够，后端应用要提供真实反映运行状态的接口：
- 暴露专用健康端点，如
/ready或/actuator/health，不走业务链路 - 该接口应在应用完全初始化（数据库连接、缓存加载、配置加载完成）后再返回 200
- 若使用 K8s 或 Consul，应将该接口设为 readiness probe，确保注册中心只推送“真正就绪”的实例给 Nginx
- 防火墙或 WAF 需放行健康探测路径，否则探测永远失败，节点无法恢复
只要参数配对、探测路径可达、后端响应可信，Nginx 就能在几秒到几十秒内完成“故障剔除 → 恢复探测 → 自动重入”的闭环。
