vip漂移由keepalived基于vrrp协议控制网卡绑定/解绑实现，nginx仅提供服务且需通过外部脚本检测健康状态；state、priority、virtual_router_id三者必须严格对齐，防火墙须放行224.0.0.18组播流量。
直接说结论：VIP 漂移不是靠 Nginx 自身实现的，而是由 Keepalived 基于 VRRP 协议控制网卡绑定/解绑虚拟 IP（VIP）完成的；Nginx 只负责提供 Web 服务，它的健康与否必须通过外部脚本被 Keepalived 检测，否则 VIP 会“僵在故障节点”上不动。
keepalived.conf 里 state、priority、virtual_router_id 必须严格对齐
两个节点的配置不是“差不多就行”，而是三处必须完全一致或明确反向：
-
state：主节点写MASTER，备节点写BACKUP—— 写反会导致双 MASTER 或双 BACKUP，VIP 不会漂移 -
priority：主节点数值必须高于备节点（如100vs90），且差值要大于脚本weight的绝对值（比如weight -20，那优先级差至少得 >20） -
virtual_router_id：必须相同（范围 1–255），否则两节点根本不在同一个 VRRP 组里，互不感知
常见错误现象：ip addr show 看不到 VIP，或者 VIP 同时出现在两个节点上 —— 八成是这三项没对齐。
/etc/keepalived/nginx_check.sh 脚本必须能真实反映 nginx 进程状态
很多教程给的检测脚本只查 ps -C nginx，但实际中 nginx 可能处于 “假死” 状态：进程存在、端口监听着、但返回 502 或超时。这种情况下 VIP 不该漂移，但脚本却认为“正常”。
更可靠的检测方式是加 HTTP 请求验证：
#!/bin/bash
if ! curl -f -s --connect-timeout 3 http://127.0.0.1:80/healthz > /dev/null 2>&1; then
systemctl stop keepalived
fi
使用要点：
- 确保 Nginx 配置了
location /healthz { return 200; }或类似探针路径 -
curl -f表示失败时返回非零退出码，systemctl stop keepalived才会触发 - 不要用
sleep+ 二次检查 —— Keepalived 本身有interval和fall/rise参数控制检测稳定性
防火墙必须放行 VRRP 组播流量 224.0.0.18
Keepalived 默认用 VRRP 协议发心跳，目标地址是组播 IP 224.0.0.18，协议类型是 vrrp。如果防火墙拦住这个包，节点间就“失联”，BACKUP 会立刻升为 MASTER，造成脑裂。
不同防火墙命令不同，但核心都是放开这个规则：
- iptables：
-A INPUT -p vrrp -d 224.0.0.18/32 -j ACCEPT - firewalld：
firewall-cmd --direct --permanent --add-rule ipv4 filter INPUT 0 --destination 224.0.0.18 --protocol vrrp -j ACCEPT
验证是否生效：tcpdump -i eth0 host 224.0.0.18，主节点启 keepalived 后应能看到周期性组播报文。
nginx 启动顺序和用户权限容易被忽略
Keepalived 启动时会尝试调用 nginx_check.sh，而该脚本若执行 systemctl start nginx 或 /usr/local/nginx/sbin/nginx，必须满足：
- Nginx 二进制路径要写绝对路径（
/usr/local/nginx/sbin/nginx），不能依赖 PATH - 脚本运行用户是 root（Keepalived 主进程是 root），但 Nginx worker 进程通常降权为
www或nginx用户 —— 检查nginx.conf中的user指令是否与系统用户一致 - 确保
nginx -t在任意节点上都能通过，配置语法错误会导致启动失败，进而让检测脚本反复触发停 keepalived
最隐蔽的问题：SELinux 启用时，Keepalived 调用脚本启动 Nginx 可能被拒绝，setenforce 0 是临时验证手段，生产环境需配对应策略而非直接关闭。
