VIP漂移失败首要原因是配置网卡名与实际接口不匹配，需用ip -br a确认真实名称；其次检查VIP子网是否直连、云平台限制、ARP响应是否发出及内核arp_ignore/arp_announce参数是否正确设置并持久化。
检查 vip 配置中网卡名是否匹配实际接口
很多 vip 漂移失败，根本原因是配置里写的网卡名（比如 eth0）在目标节点上根本不存在——可能是 ens192、enp0s3，甚至用了 systemd 的可预测命名规则后变成 eno1。系统不会自动映射，只认字面匹配。
- 用
ip -br a或ls /sys/class/net/确认当前节点真实网卡名，别信旧文档或备份配置 - 检查高可用软件（如
keepalived、corosync+pacemaker）的配置文件，确认interface字段值与实际一致，例如：interface ens192 - 容器或云环境更易出问题：AWS EC2 可能是
eth0，但同一镜像在 VMware 里可能是ens160；K8s 中用hostNetwork: true时也要核对宿主机接口名
验证 VIP 所在子网是否真正在本地路由表中可达
VIP 必须落在某个本地网卡的直连子网内，否则内核会拒绝绑定（常见错误：SIOCSIFFLAGS: Cannot assign requested address）。这不是配置错，而是网络层根本不允许。
- 运行
ip r | grep "dev.*[a-z]"查看所有直连子网，确认 VIP 的 IP 是否落在其中某条xx.xx.xx.xx/yy dev eth0 proto kernel scope link src zz.zz.zz.zz的范围内 - 特别注意：如果用了 VLAN 子接口（如
eth0.100），VIP 必须属于该子接口的子网，不能写在物理口主网段里 - 云平台（如阿里云、腾讯云）常禁用非主网卡绑定 VIP，即使路由表显示可达，也会被底层拦截——得查云厂商文档是否支持“辅助私有 IP”或“多 IP 绑定”
抓包确认 ARP 响应是否发出（arping + tcpdump）
配置和路由都对，但客户端仍无法访问 VIP？大概率是 ARP 广播没发出去，或者发了但没被响应——这时候光看日志没用，得看实际报文。
- 在 VIP 所在节点执行：
arping -I ens192 -c 3 192.168.1.100（把ens192和192.168.1.100换成你的真实接口和 VIP），观察是否收到 reply - 同时另开终端跑：
tcpdump -i ens192 arp host 192.168.1.100，看是否有who-has请求发出、有没有tell响应回来 - 常见静默失败点：交换机端口启用了
arp inspection或port security，会丢弃非“合法 MAC”的 ARP 响应；物理网卡驱动不支持arp_ignore/arp_announce也会导致响应发错源地址
留意 arp_ignore 和 arp_announce 内核参数影响
Linux 默认行为是：只要本机有任一接口配了该 IP，就响应所有网段来的 ARP 请求。这在 VIP 场景下极危险——会导致非主节点也应答，引发流量黑洞或双主冲突。
- 必须设置：
net.ipv4.conf.all.arp_ignore = 1（只响应目标 IP 在请求入接口上的 ARP）和net.ipv4.conf.all.arp_announce = 2（选择最佳本地地址回应 ARP） - 注意作用域：
all不覆盖lo或具体接口（如ens192），如果 VIP 绑在lo上（常见于 LVS DR 模式），还得单独设net.ipv4.conf.lo.arp_ignore = 1 - 这些参数是运行时生效的，但重启失效；要持久化得写进
/etc/sysctl.conf或对应/etc/sysctl.d/*.conf，且需sysctl -p加载
最麻烦的不是参数没设，而是设了但没生效——比如 systemd-sysctl 启动顺序早于网络服务，导致 VIP 已绑上才加载参数。这种时候得查 systemctl status systemd-sysctl 日志，再配合 sysctl net.ipv4.conf.all.arp_ignore 实时确认值。
