Nginx开源版不支持主动心跳监测，仅提供被动健康检查（max_fails/fail_timeout）；主动探测需第三方模块（如nginx_upstream_check_module）或外部工具（Consul、脚本等）。
Nginx 本身不直接提供“心跳监测”功能，upstream 模块也没有内置的主动探活（health check）机制。所谓“后端存活心跳监测”，在标准 Nginx（开源版）中需依赖第三方模块（如 nginx_upstream_check_module）或借助外部工具（如 Consul、Zabbix、自定义脚本 + API）实现。官方版本仅支持被动健康检查（fail_timeout / max_fails），即通过请求失败来间接判断节点是否异常。
被动健康检查：Nginx 原生支持的方式
这是最常用、无需额外编译模块的方法，适用于大多数简单场景：
-
max_fails：在
fail_timeout时间窗口内，允许后端服务器连续失败多少次；超过则标记为不可用 - fail_timeout：失败计数器重置时间，同时也是被标记为不可用的持续时长
-
proxy_next_upstream：定义哪些响应状态或错误会触发重试（如
error timeout http_500 http_502）
示例配置：
<pre>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;
}
server {
location / {
proxy_pass http://backend;
proxy_next_upstream error timeout http_500 http_502;
proxy_next_upstream_tries 2;
}
}
</pre>
主动健康检查：需引入第三方模块
若需定期向后端发送探测请求（如 HTTP GET /health），必须使用 nginx_upstream_check_module（由淘宝开源，已多年稳定使用）：
- 需重新编译 Nginx，添加该模块（不支持动态加载）
- 支持 TCP、HTTP、SSL 探测，可自定义检查 URI、期望状态码、超时等
- 提供
/status页面查看实时健康状态（需配合check_status指令）
启用后典型配置片段：
<pre>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 "GET /health HTTP/1.0\r\n\r\n";
check_http_expect_alive http_2xx http_3xx;
}
server {
location /status {
check_status;
allow 127.0.0.1;
deny all;
}
}
</pre>
替代方案：用外部服务协调健康状态
适合微服务或容器化环境，解耦 Nginx 与健康逻辑：
- 使用 Consul 或 Nacos 管理后端服务注册与健康检查，Nginx 通过 Lua（OpenResty）或定期拉取服务列表动态更新 upstream
- 用 systemd / supervisor 监控后端进程，异常时调用 Nginx API（需启用
ngx_http_api_module或 reload 配置） - 编写定时脚本 curl 后端健康接口，失败时执行
nginx -s reload切换 upstream 配置（简单但有延迟）
注意事项与常见误区
避免踩坑的关键点：
- 被动检查不是“心跳”，它不主动发包，只在流量经过时累积失败；空闲节点即使宕机也不会被及时发现
-
max_fails=0表示禁用失败计数，节点永不被标记为 down（慎用） - 主动模块的
rise和fall要合理设置：过小易误判，过大导致故障恢复慢 - HTTP 探测路径（如
/health）必须轻量、无副作用，且后端真实实现并返回预期状态码
