nginx开源版默认仅支持被动健康检查，需借助第三方模块（如nginx_upstream_check_module）或升级nginx plus实现主动探测；被动方式通过max_fails和fail_timeout自动剔除并恢复节点。
Nginx 本身不内置主动健康检查（Active Health Check）功能，但可通过 nginx-plus（商业版）或借助 第三方模块（如 nginx_upstream_check_module） 实现。开源版 Nginx 默认仅支持被动健康检查（Passive Health Check），即通过请求失败自动标记节点为不可用，并在一定时间后尝试恢复。下面分场景说明如何配置自动剔除死节点：
使用开源 Nginx + upstream_check_module（推荐开源方案）
该模块由淘宝开源，已广泛用于生产环境，支持 TCP/HTTP 层主动探测，可配合 keepalived 或自定义脚本实现故障转移。
- 需自行编译 Nginx，添加
nginx_upstream_check_module模块（注意版本兼容性，如适配 Nginx 1.20+ 需用较新 fork 分支） - 在
upstream块中启用检查，例如：
upstream backend {
server 192.168.1.10:8080;
server 192.168.1.11:8080;
check interval=3 rise=2 fall=5 timeout=1 type=http;
check_http_send "HEAD /health HTTP/1.0\r\n\r\n";
check_http_expect_alive http_2xx http_3xx;
}
说明：
interval=3：每 3 秒探测一次
rise=2：连续 2 次成功则恢复节点
fall=5：连续 5 次失败则标记为 down 并剔除流量
type=http：发送 HTTP 探针（也可选 tcp）
/health 需确保后端服务真实提供该轻量接口，返回 2xx/3xx 状态码
使用 Nginx Plus（官方商业版）
原生支持高级健康检查，无需编译，配置简洁且含可视化监控。
- 启用主动检查只需在 upstream 中添加
health_check指令：
upstream backend {
server 192.168.1.10:8080;
server 192.168.1.11:8080;
health_check interval=5 passes=2 fails=3 uri="/health" match=healthy;
}
match healthy {
status 200;
header Content-Type = "application/json";
body ~ "status.*ok";
}
该配置表示：每 5 秒请求 /health，连续 2 次匹配成功则恢复，连续 3 次失败则剔除；支持状态码、响应头、响应体正则匹配，灵活性高。
仅用开源 Nginx（无第三方模块）的被动方式
虽不能主动探测，但可通过 max_fails 和 fail_timeout 实现“故障感知→临时剔除→自动恢复”闭环：
- 示例配置：
upstream backend {
server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;
server 192.168.1.11:8080 max_fails=3 fail_timeout=30s;
}
含义：某节点在 30 秒内连续 3 次请求失败（超时或返回 5xx），Nginx 将其标记为不可用，期间不再转发请求；30 秒后自动重试，若成功则恢复服务。适合对延迟敏感度不高、后端自身有兜底能力的场景。
配套建议：让剔除更可靠
-
后端务必暴露真实健康接口（如
/health），避免只检查端口通断——端口通但进程卡死或 DB 断连时无法识别 - 检查路径要轻量：不查 DB、不加载大资源，响应时间控制在 100ms 内，避免探针拖慢集群
-
结合日志与告警：开启
log_format记录 upstream 状态，配合 ELK 或 Prometheus + nginx-vts-exporter 监控节点 up/down 变化 - 避免单点误判：rise/fall 参数不宜过激（如 rise=1 fall=1 易抖动），建议 rise≥2、fall≥3
