Nginx无原生主动心跳，需依赖第三方模块或被动机制；推荐interval=2000ms、timeout< interval（如500–800ms）、fall=3、rise=2，并优化/healthz接口与proxy_next_upstream兜底。
Nginx 本身不提供原生主动心跳检测，所谓“心跳频率”实际是通过第三方模块（如 nginx_upstream_check_module）或被动机制间接实现的。配置时不能只看数字大小，关键在平衡探测灵敏度与系统开销——太密会压垮后端、拖慢 Nginx worker；太疏则故障窗口拉长，影响可用性。
心跳间隔（interval）直接影响探测压力
这是最核心的性能变量：
- 小于 1000ms（如 500ms）易引发并发探测堆积，尤其当 upstream 节点较多时，worker 可能因等待响应而阻塞，吞吐下降
- 超过 10s（如 15s）虽减轻负载，但单节点宕机后平均需 7.5 秒以上才被摘除，SLA 难以保障
- 推荐值为 2000ms：兼顾多数无状态服务的响应能力与故障发现时效，实测中 CPU 和连接数波动平稳
超时（timeout）必须严格小于 interval
否则探测未完成就发起下一轮，导致状态错乱、误判率上升：
- timeout 设为 1000ms 时，interval 至少设为 2000ms
- 若后端
/healthz平均耗时 300ms，timeout 可设为 500–800ms，留出缓冲余量 - TCP 模式下 timeout 可更低（如 300ms），HTTP 模式建议不低于 500ms，避免网络抖动干扰
rise 和 fall 值决定状态切换稳定性
它们不直接影响 CPU 或带宽，但显著影响误踢和恢复延迟：
- fall=3：连续 3 次失败才下线，可过滤瞬时 GC、慢 SQL 或网络闪断，避免频繁震荡
- rise=2：连续 2 次成功即恢复，防止健康节点长期闲置，提升资源利用率
- 对有状态服务（如带 session 的 Java 应用），可调高 fall 至 4–5，降低误判风险
探测路径与响应设计也属于性能环节
轻量、独立、快速的健康接口才能支撑高频心跳：
- 后端
/healthz不应查数据库、不依赖 Redis、不加载业务逻辑，纯内存检查进程存活+端口通 - 响应体为空，仅返回
200 OK，头部精简（禁用Transfer-Encoding: chunked） - 使用
HEAD方法代替GET，减少传输开销；若后端不支持 HEAD，用GET /healthz HTTP/1.0并加\r\n\r\n结尾
被动重试机制仍需保留，它不增心跳开销但补足容错proxy_next_upstream 是零额外探测成本的兜底手段：
- 配置
error timeout http_502 http_503 http_504覆盖常见失败场景 -
proxy_next_upstream_tries 2限制最多转发两次，防雪球 - 它不改变 upstream 状态，但让首请求失败用户几乎无感——这是主动心跳无法替代的体验层优化
不复杂但容易忽略
