Keepalived VIP漂移稳定性关键在于减少误切换：启用非抢占模式（全节点state BACKUP+显式nopreempt）、拉大优先级差值（≥50）、关闭vrrp_strict、用track_script绑定业务健康度。
Keepalived 的 VIP 漂移稳定性，关键不在“怎么让它动得更快”，而在于“怎么让它别乱动”。默认抢占模式下，一次网络抖动、服务重启或短暂心跳丢失，就可能触发 VIP 来回切换，造成业务二次中断。真正稳定的漂移，是**少切换、不反复、可预期**。以下是几个实操性强、生产环境验证有效的优化方向。
统一设为 BACKUP 状态 + 显式启用 nopreempt
这是非抢占模式的基石配置，但很多人只做一半。必须同时满足两个条件：
- 所有节点的 state 都要设为 BACKUP（不是一主一备）；
- 在所有节点的 vrrp_instance 块中，显式添加 nopreempt 参数。
示例片段：
vrrp_instance VI_1 {
state BACKUP
interface eth0
virtual_router_id 51
priority 100
advert_int 1
nopreempt # 必须写在这里，全局无效
authentication { ... }
virtual_ipaddress { 192.168.1.100/24 }
}注意：只在备节点加 nopreempt 不生效；只改 priority 不改 state，也可能因版本差异导致行为异常。
优先级差值拉大，避免临界竞争
当两个节点 priority 过于接近（比如 100 和 99），网络延迟或时钟偏差可能导致 VRRP 报文处理顺序错乱，引发短暂角色震荡。建议：
- 主节点设为 100 或更高（如 150）；
- 备节点设为 ≤ 50（如 40 或 30）；
- 差值 ≥ 50，留足缓冲空间，降低误判概率。
这不是为了“抢得更狠”，而是为了让状态决策更笃定——只要心跳通，谁该持 VIP 就毫无争议。
关闭 vrrp_strict（除非真需要合规审计）
vrrp_strict 是 Keepalived 的严格校验模式，它会强制要求：
- VRRP 报文源 IP 必须是本地直连网段；
- 必须使用组播地址 224.0.0.18；
- 禁止单播通信等“非标准”行为。
这些限制在多数私有网络中并无必要，反而容易因防火墙策略、云厂商VPC组播限制或容器网络模型导致心跳失败、VIP无法漂移。生产环境建议：注释掉或删除 vrrp_strict 行，让 Keepalived 更适应真实网络环境。
用 track_script 替代纯 priority 依赖
单纯靠 priority 切换 VIP，本质是“看心跳”，但心跳正常 ≠ 服务可用。更稳的做法是把 VIP 绑定到实际业务健康度上：
- 写一个轻量脚本（如检测 Nginx 进程、端口连通性或 HTTP 返回码）；
- 用 track_script 关联该脚本，并设置 weight（如 -20）；
- 当服务异常时，自动扣减 priority，触发漂移；服务恢复后，priority 自动回升。
这样 VIP 只会在“服务真挂了”时才动，而不是“网卡闪一下”就切，大幅减少误漂移。
稳定不是靠调高频率或加冗余，而是靠收窄触发条件、明确决策依据、消除模糊地带。Keepalived 本身足够可靠，问题常出在配置与业务场景错配。按这四点调，VIP 就不再“飘忽”，而变得“可信”。
