nginx原生不支持真正的http心跳检测，需依赖第三方模块nginx_upstream_check_module实现主动健康探测；该模块支持定时请求/healthz等接口并校验状态码，需编译加载、配置check指令及禁用max_fails被动机制。
Nginx 原生不支持真正的 HTTP 心跳检测，它自带的 max_fails + fail_timeout 只是被动容错机制——请求发出去失败后才标记节点异常，首请求必然可能打到宕机节点，延迟高、体验差。要实现主动、可控、贴近业务真实状态的 HTTP 心跳检测，必须使用第三方模块 nginx_upstream_check_module。
这个模块由淘宝开源，已广泛用于生产环境，支持基于 HTTP 协议定期探测后端 /healthz、/actuator/health 等轻量健康接口，并校验响应内容和状态码，真正实现“未请求先发现”。
启用前确认模块已加载
运行命令：
nginx -V 2>&1 | grep -o 'upstream_check'
若无输出，说明模块未编译进 Nginx。需下载与当前 Nginx 版本（如 1.22.1）严格匹配的源码和对应 patch，打补丁后重新 configure（加 --add-module=/path/to/nginx_upstream_check_module），再 make && make install。
在 upstream 块中配置 HTTP 心跳探测
upstream backend {
server 10.0.1.10:8080;
server 10.0.1.11:8080;
# 启用主动 HTTP 探测（必须写在 upstream 内，且只出现一次）
check interval=3000 rise=2 fall=3 timeout=1000 type=http;
check_http_send "GET /health HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n";
check_http_expect_alive http_2xx http_3xx;
}
-
interval=3000：每 3 秒探测一次（推荐 2–5 秒，太短易压垮后端，太长故障窗口大） -
rise=2：连续 2 次成功，标记为恢复上线 -
fall=3：连续 3 次失败，才标记为 down（避免网络抖动误判） -
timeout=1000：单次探测超时设为 1 秒，防止阻塞 -
type=http：显式指定类型，否则子指令（如check_http_send）不生效 -
check_http_send：发送完整 GET 请求（比 HEAD 更可靠，便于后端返回 JSON 结构体） -
check_http_expect_alive：仅当响应码为 2xx 或 3xx 才视为健康（不建议只认 200）
禁用原生被动机制，避免干扰
每个 server 行应显式关闭默认容错：
server 10.0.1.10:8080 max_fails=0 fail_timeout=0;
暴露健康状态页，便于监控与排查
在 http 块中添加：
location /status {
check_status html;
access_log off;
allow 127.0.0.1;
allow 10.0.0.0/8; # 仅允许内网监控系统访问
deny all;
}
访问 http://your-nginx-ip/status 可查看各节点实时状态（up/down）、Rise/Fall 计数、最后检测时间等。
搭配 proxy_next_upstream 做兜底重试
在 location 中补充：
proxy_next_upstream error timeout http_502 http_503 http_504; proxy_next_upstream_tries 2; proxy_next_upstream_timeout 3s;
注意：该机制不摘除节点，仅对单次失败请求做转发重试，必须与上游主动心跳配合，才能真正隔离故障实例。
不复杂但容易忽略
