nginx原生不支持主动http心跳检测，需依赖nginx_upstream_check_module模块；核心参数为interval、timeout、rise、fall，配合check_http_send和check_http_expect_alive实现精准健康检查，并需保留proxy_next_upstream被动容错。
Nginx 本身不支持原生的主动 HTTP 心跳检测（即定期发健康探针），它默认的 max_fails + fail_timeout 是被动容错机制，不是真正的心跳。要实现可调的后端 HTTP 心跳时间，必须借助第三方模块 nginx_upstream_check_module，并配合合理的参数组合。
心跳时间由哪些参数决定
核心是 check 指令中的四个关键值：
-
interval：两次探测之间的间隔（毫秒），直接决定心跳频率 -
timeout：单次探测等待响应的上限（毫秒） -
rise：连续成功多少次才标记为“恢复” -
fall：连续失败多少次才标记为“宕机”
例如：
check interval=2000 rise=2 fall=3 timeout=1000 type=http;
表示每 2 秒发起一次 HTTP 探测，超时 1 秒即判失败，连续 3 次失败下线，连续 2 次成功上线。
正确配置 HTTP 心跳路径与响应判断
光有 check 不够，还需指定探测行为和成功标准：
-
check_http_send：构造轻量请求，推荐用GET /healthz HTTP/1.1\r\nHost: example.com\r\n\r\n -
check_http_expect_alive：只把http_2xx或http_3xx当作健康响应，避免误判 5xx 或重定向陷阱
确保后端 /healthz 接口：
- 响应快（建议
- 不依赖数据库或缓存（只检查进程存活+基础依赖）
- 返回明确的 200 状态码
避免常见时间设置陷阱
- ❌
interval （如 500ms）：易触发并发探测堆积，增加后端压力，且 Nginx worker 可能阻塞 - ❌
interval > 10000（如 15s）：故障发现窗口过长，影响服务可用性 SLA - ❌
timeout ≥ interval：探测还没结束就发起下一轮，导致状态混乱 - ✅ 推荐中等强度组合（适用于大多数无状态 API）：
-
interval=2000 -
timeout=1000 -
rise=2 -
fall=3
-
被动兜底仍需保留
主动心跳不能替代 proxy_next_upstream 的容错能力：
proxy_next_upstream error timeout http_502 http_503 http_504; proxy_next_upstream_tries 2; proxy_next_upstream_timeout 3s;
它不摘除节点，但在首次请求失败时快速转向其他后端，减少用户感知延迟——这是主动心跳的重要补充。
不复杂但容易忽略
