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;
}
</font>
<p>说明：<br>
<strong>interval=3</strong>：每 3 秒探测一次<br>
<strong>rise=2</strong>：连续 2 次成功则恢复节点<br>
<strong>fall=5</strong>：连续 5 次失败则标记为 down 并剔除流量<br>
<strong>type=http</strong>：发送 HTTP 探针（也可选 tcp）<br>
<strong>/health</strong> 需确保后端服务真实提供该轻量接口，返回 2xx/3xx 状态码</p>
<H3>使用 Nginx Plus（官方商业版）</H3>
<p>原生支持高级健康检查，无需编译，配置简洁且含可视化监控。</p><div class="aritcle_card flexRow">
<div class="artcardd flexRow">
<a class="aritcle_card_img" href="/xiazai/skill6848" title="Nginx Hosting"><img
src="https://img.php.cn/upload/skill/000/000/081/179116929868126.jpg" alt="Nginx Hosting" ></a>
<div class="aritcle_card_info flexColumn">
<a href="/xiazai/skill6848" title="Nginx Hosting">Nginx Hosting</a>
<p>通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。</p>
</div>
<a href="/xiazai/skill6848" title="Nginx Hosting" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a>
</div>
</div>
<ul>
<li>启用主动检查只需在 upstream 中添加 <code>health_check</code> 指令：</li>
</ul>
<font color="#666">
<pre class="brush:php;toolbar:false;">
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
