Nginx 中健康检查如何配置当后端恢复时自动重新加入集群调度

Nginx支持后端节点故障恢复后的自动重入调度，需正确配置被动或主动健康检查：被动检查依赖max_fails/fail_timeout与proxy_next_upstream触发试探请求；主动检查需nginx_upstream_check_module实现周期探活，并配合后端就绪接口与网络放行。

Nginx 默认支持后端节点故障恢复后的自动重新纳入调度，但必须正确配置健康检查参数，否则节点可能长期“离线”不被重试。关键在于让 Nginx 明确知道：什么时候算“已恢复”，以及“多久后重试”。

被动检查场景：靠请求失败触发摘除，靠时间窗口自动试探恢复

这是开源 Nginx 原生能力，无需额外模块，依赖 proxy_next_upstream 和 upstream 中的 max_fails/fail_timeout：

1. 每个 server 行必须显式设置：max_fails=3 fail_timeout=30s（示例值），表示连续失败 3 次后，该节点在 30 秒内不参与调度
2. 30 秒到期后，Nginx 会自动发起一次试探性请求；若成功，立即重新标记为可用，后续流量正常进入
3. location 中需启用重试逻辑：proxy_next_upstream error timeout http_500 http_502 http_503 http_504，确保失败能触发切换
4. 注意：没有请求打过去时，不会主动探测；所以恢复后首次请求可能略慢（要等试探请求完成）

主动检查场景：定时探活 + 状态判定，恢复更及时可靠

使用 nginx_upstream_check_module（常见于 OpenResty 或手动编译版本），可实现真正意义上的周期性健康探测：

1. 在 upstream 块中添加 check 指令，例如：check interval=3 rise=2 fall=5 type=http
2. rise=2 表示连续 2 次探测成功，才将节点从“不可用”状态升为“可用”
3. fall=5 表示连续 5 次失败才降级，避免网络抖动误判
4. 搭配 check_http_expect_alive http_2xx http_3xx，只认 2xx/3xx 为健康，排除临时 503 等响应
5. 务必设 default_down=true，防止 Nginx 启动时把未就绪节点当健康节点用

后端服务自身需配合就绪信号

仅靠 Nginx 配置还不够，后端应用要提供真实反映运行状态的接口：

1. 暴露专用健康端点，如 /ready 或 /actuator/health，不走业务链路
2. 该接口应在应用完全初始化（数据库连接、缓存加载、配置加载完成）后再返回 200
3. 若使用 K8s 或 Consul，应将该接口设为 readiness probe，确保注册中心只推送“真正就绪”的实例给 Nginx
4. 防火墙或 WAF 需放行健康探测路径，否则探测永远失败，节点无法恢复

只要参数配对、探测路径可达、后端响应可信，Nginx 就能在几秒到几十秒内完成“故障剔除 → 恢复探测 → 自动重入”的闭环。