Nginx集群健康检查需区分被动响应与主动探测：proxy_next_upstream依赖请求失败触发摘除，max_fails=3/fail_timeout=30s；nginx_upstream_check_module支持定时HTTP/TCP探活，需配置check指令、/health路径及防火墙白名单，并暴露status页接入监控。

Nginx 集群的健康检查不能只靠“连得上就算健康”，必须区分被动响应和主动探测两种逻辑，否则容易漏判、误判或延迟发现故障。

用 proxy_next_upstream 实现基础被动检查
这是开源 Nginx 原生支持的方式，无需编译模块，适合流量稳定、对故障发现延迟容忍度较高的场景。它依赖真实请求失败来触发节点摘除。

• 在 upstream 中为每个后端明确配置 max_fails 和 fail_timeout：
  • max_fails=3 表示连续 3 次失败才标记为不可用
  • fail_timeout=30s 表示该节点将被屏蔽 30 秒，之后自动试探恢复
• 在 location 中启用 proxy_next_upstream，定义哪些情况算“失败”并重试：
  • error timeout http_500 http_502 http_503 http_504 是常用组合
  • 避免加入 http_404 或 invalid_header，除非业务确认这些一定代表后端异常
• 注意：这个机制不发心跳，没请求就不会检查；节点刚启动但应用未就绪时，流量仍会打过去

用 nginx_upstream_check_module 实现主动探测
要真正实现“定时探活”，必须使用这个开源增强模块（常见于 OpenResty 或手动编译版本），它支持 HTTP/TCP 级别的周期性检查。

• 编译安装模块后，在 upstream 块中添加 check 指令：
  • 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 只把 2xx/3xx 当健康，排除 503 等临时错误
• 关键细节：
  • rise=2 防止偶发抖动导致误恢复，fall=5 避免单次丢包就下线
  • 探测路径建议用专用接口（如 /actuator/health 或 /ready），不走业务链路
  • 必须配 default_down=true，防止 Nginx 启动时把未就绪节点当健康节点用

适配防火墙与网络策略
很多“假死”不是后端真挂了，而是健康检查被中间设备拦截。

• 先定位拦截层：是 iptables 丢包？安全组限速？还是 WAF 拦截了 /health 路径？
• 若无法改防火墙，可调整探测行为：
  • 改用 type=tcp 检查端口连通性，绕过路径和头校验
  • 把 interval 放宽到 10–30 秒，降低探针频率
  • 去掉 check_http_expect_alive http_503，避免 GC 导致的短暂 503 被误判
• 后端应暴露独立健康端点，并确保该路径在防火墙白名单中显式放行

暴露状态页并接入监控闭环
光检查不够，还得让人和系统看得见、告得准。

• 配置一个 status location，例如：

  location /upstream_status {
      check_status;
  }

  它返回 HTML 或 JSON 格式的实时节点状态

  

  Nginx Hosting

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

  下载
• 把这个接口接入 Prometheus（配合 nginx-vts-exporter 或自定义采集器）
• 对 fall 触发、rise 恢复等事件写入日志，并配置 ELK 或 Loki 告警规则

不复杂但容易忽略