nginx高可用心跳分两层：一是nginx对上游后端的主动健康检查（http/tcp），依赖nginx_upstream_check_module；二是keepalived对nginx节点的主备心跳，通过vrrp+进程检测实现vip漂移。
Nginx 高可用方案中的自动心跳检测，核心是分两层实现：**Nginx 与上游后端服务之间的心跳（健康检查）**，以及**Nginx 节点自身与 Keepalived 主备节点之间的心跳（故障切换）**。两者目标不同、机制不同，需分别配置和协同处理。
上游后端服务的主动健康检查
这是 Nginx 对其代理的业务服务器（如 Tomcat、Spring Boot 应用）是否存活的探测，避免把请求发给已宕机的节点。原生 Nginx 仅支持被动容错（靠 max_fails/fail_timeout），推荐使用增强模块 nginx_upstream_check_module（Tengine 衍生或手动编译集成）实现主动 HTTP/TCP 心跳：
-
HTTP 模式：Nginx 定期向后端
/health或/status发送 HEAD 请求，校验返回状态码（如2xx或3xx）；需确保后端提供轻量健康接口 - TCP 模式：仅建立 TCP 连接并确认端口可通，不依赖应用层响应，开销更小但粒度较粗
-
关键参数示例：
check interval=3000 rise=2 fall=5 timeout=1000 type=http—— 每 3 秒探测一次，连续 2 次成功标记为恢复，连续 5 次失败标记为下线，单次超时 1 秒 -
配套监控页：在
http块中添加location /status { check_status html; }，即可通过浏览器查看实时节点状态
Nginx 节点自身的主备心跳（Keepalived 层）
这是保障 Nginx 反向代理层本身不单点的关键。Keepalived 通过 VRRP 协议在主（MASTER）和备（BACKUP）节点间传递心跳包，一旦主节点失联，VIP（虚拟 IP）自动漂移到备节点：
-
基础心跳机制：主节点周期性（
advert_int 1）以组播方式发送 VRRP 报文，备节点持续监听；若连续多个周期收不到，触发接管流程 -
增强可靠性：不能只依赖网络层心跳，必须叠加对 Nginx 进程的存活检测。常用方式是定义
vrrp_script执行 shell 脚本（如检查ps aux | grep nginx或访问本地127.0.0.1:80/health） -
权重联动：脚本检测失败时，通过
weight -2降低主节点优先级，使其主动让出 MASTER 地位，避免“脑裂” - 注意点：Keepalived 必须与 Nginx 同机部署；防火墙需放行 VRRP 组播（协议号 112，目的地址 224.0.0.18）
常见问题与处理建议
实际运行中容易忽略的细节会直接影响心跳有效性：
-
时间参数要匹配：Keepalived 的
advert_int（如 1s）应远小于fail_timeout（如 30s），否则上游故障可能还没被 Nginx 摘除，VIP 就已漂移，导致新流量继续打到故障 Nginx 上 - 避免检测干扰：HTTP 健康检查路径不应走完整业务链路（如避免调用 DB），推荐独立轻量接口；TCP 检查则需确保后端端口监听稳定，不因连接数满而拒绝
-
日志与告警必须开启：启用
error_log /var/log/nginx/upstream_check.log notice;记录健康检查事件；Keepalived 日志可通过syslog收集，并对接 Prometheus+Alertmanager 实现异常自动通知 -
不要忽略 fail_timeout 的重试窗口：原生
max_fails=5 fail_timeout=10s意味着 10 秒内失败 5 次才摘除，期间所有请求仍会轮询尝试——这对高敏感服务风险较大，务必结合主动检查模块替代
两层心跳各司其职：上游检查保后端可用，Keepalived 心跳保入口不中断。配置时需明确边界、合理设参、闭环验证，才能真正落地可靠的高可用。
