vip漂移后服务不可访问，首要确认vip实际归属节点（仅一台应显示up），再验证该节点服务是否监听vip或0.0.0.0对应端口，排除回环监听、配置未重载问题；同步检查arp宣告与客户端/交换机缓存是否更新，并用tcpdump抓包确认流量是否抵达当前主节点。
当Linux服务器使用Keepalived或Heartbeat等工具配置VIP（虚拟IP）后发生飘移，服务却无法通过该VIP正常访问，说明流量未正确导向当前主节点或服务未在新主节点上就绪。这类问题常出现在高可用集群切换后，业务请求持续超时或直接拒绝。
确认当前VIP实际归属节点
在所有参与VIP漂移的节点上依次执行：ip addr show | grep -A2 "inet.*virtual" 或更精准地 ip -br addr | grep -E "(eth|ens|enp)[0-9]+.*<strong>【VIP地址】</strong>"。
只有一台机器应显示该VIP处于UP状态；若多台都显示，说明ARP缓存未刷新或Keepalived脑裂未收敛，需立即检查vrrp_instance状态。
若无任何节点显示该VIP，说明Keepalived进程已退出、配置未加载或vrrp_script返回非0导致权重归零——此时VIP根本未绑定，后续排查全部无效。
验证服务进程是否在VIP所在节点真实监听
在上一步确认的VIP归属节点上，运行：ss -tlnp | grep :<strong>【服务端口】</strong>。
重点看第四列（Local Address:Port）：若显示为 127.0.0.1:端口 或 ::1:端口，服务仅监听回环，**外部流量无法抵达**；必须是 0.0.0.0:端口 或 <strong>【VIP地址】</strong>:端口 才可能响应VIP请求。
常见错误：Nginx/Apache配置中 listen 指令硬编码了物理网卡IP，未随VIP动态更新；MySQL bind-address 仍为 127.0.0.1；Redis未设置 bind 0.0.0.0。修改配置后务必 reload 服务，而非仅 restart。
检查ARP广播与客户端缓存是否同步
方法一：在VIP归属节点执行 arping -c 3 -I <strong>【绑定VIP的网卡名】</strong> <strong>【VIP地址】</strong>，观察是否收到响应。无响应说明本机未主动宣告ARP，可能是keepalived配置中 advert_int 过大或 garp_master_refresh 未启用。
方法二：在客户端机器执行 arp -d <strong>【VIP地址】</strong>（Linux）或 arp -d *（Windows），强制清空本地ARP缓存；再立刻 ping <strong>【VIP地址】</strong> 并用 arp -a | grep <strong>【VIP地址】</strong> 查看解析出的MAC是否为当前主节点物理网卡MAC。
若解析出的是旧主节点MAC，说明网络设备（如交换机）ARP表未更新，需在核心交换机执行 reset arp all 或等待老化时间（通常300秒）。
抓包定位流量是否到达当前主节点
第一步：在VIP归属节点执行 tcpdump -i <strong>【网卡名】</strong> host <strong>【客户端IP】</strong> and port <strong>【服务端口】</strong> -nn -w /tmp/vip_access.pcap。
第二步：从客户端发起一次真实请求（如curl或telnet）。
第三步：停止抓包，用 tcpdump -r /tmp/vip_access.pcap 查看是否有SYN包到达。若有SYN但无SYN-ACK返回，说明服务未监听或被防火墙拦截；若连SYN都没有，证明流量根本未路由到该节点——问题出在LVS/SLB层、路由策略或安全组规则。
注意：若使用云厂商负载均衡（如阿里云SLB），需确认其后端服务器健康检查已指向VIP而非物理IP，否则切换后SLB仍向旧节点转发。
