Keepalived双VIP本质是VRRP共识失效，需严查virtual_router_id、auth_pass、interface、unicast_peer四要素一致性，强制单播替代组播，并放行IP协议号112，再通过三重交叉验证确认收敛。
Keepalived 两台服务器同时拉起 VIP，本质是 VRRP 协议共识失效，不是“防不住”，而是配置或网络层没对齐。只要 virtual_router_id、auth_pass、interface、unicast_peer 四项严丝合缝，再配合防火墙放行和单播直连，双 VIP 就不会发生。
检查 virtual_router_id 和 auth_pass 是否完全一致
这是最常被忽略的硬性门槛。主备节点的 vrrp_instance 块里，这两项必须字节级相同：
-
virtual_router_id必须是同一整数（1–255），差一个数字，两个节点就自成 VRRP 组，互不识别 -
auth_pass是明文密码，区分大小写、空格、特殊字符；用echo -n "xxx" | md5sum校验两端输出是否一致更可靠 - 不要复用其他集群的 ID 或密码——哪怕只部署一套 Keepalived，也要在全局规划表里唯一标记
强制使用 unicast_peer 替代组播，绕过交换机干扰
默认组播地址 224.0.0.18 在云环境、VLAN 分割、STP 收敛期或老旧交换机上极易丢包，导致心跳中断。单播是确定性解法：
- 主节点配置中写
unicast_src_ip 192.168.1.101+unicast_peer { 192.168.1.102 } - 备节点反过来：
unicast_src_ip 192.168.1.102+unicast_peer { 192.168.1.101 } - 必须删掉
vrrp_strict（否则单播会直接报错退出） - 确保
interface值（如ens33）在两台机器上真实存在且命名一致，bond 或 team 接口要特别注意别名
验证防火墙是否放行 VRRP 协议号 112
VRRP 不走 UDP 端口，它使用 IP 协议号 112。绝大多数防火墙默认拦截该协议，而非“开放 udp/112”：
- CentOS/RHEL：
firewall-cmd --direct --permanent --add-rule ipv4 filter INPUT 0 --in-interface ens33 --destination 224.0.0.18 --protocol vrrp -j ACCEPT - Ubuntu/iptables：
iptables -A INPUT -p 112 -i ens33 -j ACCEPT - 临时关闭防火墙测试：如果关掉后 VIP 立即收敛，基本可锁定是此问题
- 云平台安全组需显式允许“协议类型：VRRP”或“IP 协议：112”，不能只开 TCP/UDP 端口
上线前必须跑通三重交叉验证
配完不等于稳，状态必须人工确认收敛：
- 执行
ip addr show | grep "inet.*VIP"—— 只有一台显示该 VIP，另一台无输出 - 在备机运行
tcpdump -i ens33 host 192.168.1.101 and proto 112 -c 5—— 应持续捕获到主节点发来的 VRRP 报文 - 从局域网外另起一台机器反复
curl -I http://VIP/health—— 响应头中的Server或日志时间戳始终来自同一台物理机
单播配置下，tcpdump 抓包目标不再是 vrrp 关键字，而是 host 对端IP and proto 112，这点容易漏掉——不验证就上线，等于把 VIP 暴露在未收敛状态里。
