keepalived 不同步 nginx 状态，而是通过本地 vrrp_script（如每2秒执行 curl 或进程检测）独立判断服务可用性，据此升降优先级触发 vip 切换；主备节点各自运行、无状态通信，依赖 vrrp 组播竞争 vip，virtual_router_id 必须一致且防火墙放行协议112。
Keepalived 本身不负责 Nginx 进程状态的“心跳同步”，它只管理 VIP（虚拟 IP）的归属和节点健康状态。所谓“主备间状态同步”，实际是通过 Keepalived 的健康检查机制间接实现的：它定期探测本地 Nginx 是否可用，再据此决定是否抢占或释放 VIP。真正的 Nginx 状态不跨节点传递，也不做实时同步。
Keepalived 如何感知 Nginx 状态
Keepalived 通过配置 vrrp_script 定义自定义检测脚本，周期性执行（如每 2 秒），根据脚本退出码（0 表示成功，非 0 表示失败）判断本地服务是否正常。常见做法是检查 Nginx 进程是否存在、端口是否监听、或返回特定 HTTP 响应。
- 在
/etc/keepalived/keepalived.conf中定义脚本：
script "/usr/bin/killall -0 nginx 2>/dev/null"
interval 2
weight -5
}
- 将该脚本绑定到 VRRP 实例中，影响优先级升降；当检测失败时，优先级降低，触发主备切换
- 注意：脚本必须有可执行权限，且路径需绝对、无依赖问题（如不依赖 bash 特性）
主备切换的关键逻辑
Keepalived 主备不是靠“通信同步”，而是各自独立运行 + 竞争 VIP。主节点持续广播 VRRP 报文，备节点监听；一旦备节点发现主节点停止通告（或自身健康检查失败），就升为 MASTER 并接管 VIP。
- VRRP 报文默认使用组播（224.0.0.18），需确保主备间三层可达、防火墙放行 UDP 112 端口
- 避免脑裂：建议配置 preempt_delay 或启用 notify 脚本，在状态变更时记录日志或触发告警
- 主备优先级需错开（如 master=100，backup=90），且 backup 节点开启 nopreempt 可防止频繁抢权（仅在 master 故障恢复后不自动切回）
常见误操作与排查点
很多故障源于配置不一致或检测逻辑失效，而非 Keepalived 本身异常。
- 主备节点的 virtual_router_id 必须相同，否则视为不同组，互不感知
- 检测脚本返回值错误：例如用
curl -f http://127.0.0.1:80但 Nginx 返回 50x 页时 curl 仍返回 0，需加-s -o /dev/null -w '%{http_code}' | grep -q "200" - SELinux 或 systemd 的 PrivateTmp=true 可能导致脚本找不到临时文件或进程名，建议关闭 PrivateTmp 或改用端口检测（
nc -z 127.0.0.1 80）
为什么不推荐依赖 Nginx 自身状态同步
Nginx 是无状态的反向代理，本身不提供主备间状态共享机制。试图用第三方工具（如 Redis、etcd）同步 upstream 配置或连接状态，会增加架构复杂度，且无法解决 VIP 切换的核心诉求——流量入口控制。
- Keepalived + Nginx 组合的本质是“故障转移”，不是“高可用集群”；真正需要会话保持或动态配置同步，应结合 Consul + Registrator 或 Nginx Plus
- 若业务要求强一致性（如秒级切换+零丢包），需配合 TCP 连接重用、客户端重试、或接入层 LB（如 LVS + Keepalived）进一步优化
