nginx无原生主动心跳，需依赖第三方模块或被动机制；推荐interval=2000ms、timeout

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 是零额外探测成本的兜底手段：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

• 配置 error timeout http_502 http_503 http_504 覆盖常见失败场景
• proxy_next_upstream_tries 2 限制最多转发两次，防雪球
• 它不改变 upstream 状态，但让首请求失败用户几乎无感——这是主动心跳无法替代的体验层优化

不复杂但容易忽略