Keepalived 实现 Nginx 集群 VIP 漂移本质是基于 VRRP 协议的主备选举与绑定，但安全漂移依赖健康感知、状态联动和内核防护：HTTP 探针检查 /healthz、动态降权配合 nopreempt、禁用 auto-start nginx、调优 arp_ignore/arp_announce、云环境改用 SLB，并通过多场景验证确保漂移可靠。
Keepalived 实现 Nginx 集群 VIP 漂移，本质是通过 VRRP 协议在主备节点间自动选举并绑定虚拟 IP，但“安全漂移”关键不在协议本身，而在于防止脑裂、误切换和网络污染。配置必须兼顾健康感知、状态联动与内核级防护，缺一不可。
健康检查脚本要真实反映服务能力
Keepalived 不监控 Nginx 进程是否存活，而是依赖 track_script 判断服务是否可用。简单检查进程或端口监听远远不够——Nginx 可能卡死、worker 全阻塞、或 upstream 全不可达，此时仍返回 200 但实际无法响应请求。
- 推荐用 HTTP 探针：访问 Nginx 本地健康接口（如
/healthz），检查返回码 + 响应体关键字，超时设为 2 秒以内 - 脚本失败后建议先尝试重启 Nginx（sleep 1–2 秒再验证），仅当连续 3 次失败才触发
systemctl stop keepalived - 避免使用
ps -C nginx类检测——Nginx master 进程常驻，但 worker 可能全部僵死
主备角色与优先级需配合 nopreempt 和权重机制
默认抢占模式（preempt）下，主节点恢复后会立即抢回 VIP，可能造成瞬断；而完全禁用抢占又会导致故障恢复后需人工干预。更稳妥的做法是启用 nopreempt，再结合健康检查动态降权。
- 主节点初始 priority 设为 100，备节点设为 90；健康检查失败时，weight -20 使其优先级降至 80，低于备节点，触发主动让位
- 主节点恢复后不立即抢主，而是等待自身健康且优先级重新高于备节点，再平滑接管
- 所有节点 不要设置 auto-start nginx，Keepalived 启动时通过 notify_master 脚本拉起 Nginx，notify_backup 停止它，避免双主风险
内核参数与网络层加固防 ARP 污染
VIP 漂移后若客户端仍向旧节点发包，说明本地或交换机 ARP 缓存未刷新——这不是 Keepalived 的问题，而是 Linux 内核对 VIP 的响应策略未调优。
- 在所有节点执行：
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignoreecho 2 > /proc/sys/net/ipv4/conf/all/arp_announce
并写入/etc/sysctl.conf永久生效 - 确保 VIP 与物理 IP 同网段，且交换机允许 VRRP 组播（224.0.0.18）或已配置单播 peer（unicast_peer）
- 云环境（如阿里云、腾讯云）不支持直接绑定 VIP，必须改用云负载均衡器（SLB/CLB）+ 多台 ECS 上的 Nginx，Keepalived 改为仅做节点健康通告或弃用
配置验证必须覆盖典型故障场景
上线前不验证等于没配。VIP 漂移时间不是越快越好，而是要在“快速响应”和“避免抖动”间平衡——通常 2–4 秒可接受，但需实测确认。
- 模拟主节点宕机：
systemctl stop keepalived，观察备节点ip addr show是否 3 秒内出现 VIP - 模拟 Nginx 异常：
pkill -f "nginx: worker"，验证脚本是否在 6 秒内（2s×3 次）触发降权并漂移 - 抓包确认：
tcpdump -i eth0 host 224.0.0.18查看 VRRP Advertisement 是否正常收发，无丢包 - 从客户端持续 curl VIP，记录最长中断时间，应 ≤ 1 个 advert_int 周期 + 网络延迟
