Keepalived切换后网络延迟的根源是ARP缓存未更新，导致流量仍发往旧MAC；需在notify脚本中主动发送多次免费ARP并定时刷新VIP相关ARP条目。
Keepalived 切换后出现网络延迟，往往不是 VIP 没切成功，而是客户端或服务器仍用着旧的 MAC 地址发包——根本原因在于 ARP 缓存未及时更新。这个问题在双机热备场景中高频发生，但排查和解决路径很清晰。
为什么切换后 ARP 缓存会“卡住”通信
Linux 系统中，ARP 条目进入 STALE 状态后不会立刻刷新，而是等待下一次数据包发送时才触发邻居检测（如发 TCP 包后进入 DELAY → PROBE）。这个过程可能耗时数秒甚至更久，期间所有发往 VIP 的流量仍按旧 MAC 封装，导致丢包或重传，表现为连接慢、超时、首包延迟高。
尤其当切换发生在业务低峰期（如夜间），很多服务器长时间没向 VIP 发包，ARP 条目长期停留在 STALE 或 FAILED，等到白天突增请求时才暴露问题。
Keepalived 自身的 ARP 行为关键点
Keepalived 在角色变更时默认只做两件事：
- 绑定/解绑 VIP 到本地网卡
- 发送一次免费 ARP（Gratuitous ARP）到局域网，宣告“VIP 现在我这”
但这个免费 ARP 只影响直连二层设备（如交换机、同一网段的客户端），对已存在 STALE 条目的服务器无效——它们不会主动响应免费 ARP，也不会立即更新缓存。这就是为什么故障恢复后要手动清 ARP 或补发免费 ARP。
快速定位与验证方法
在疑似受影响的服务器上执行：
-
sudo arp -n | grep
：查看该 VIP 对应的 MAC 是否还是老主节点的 -
ip neigh show
：看状态是 STALE、FAILED 还是 REACHABLE -
tcpdump -i any arp host
：确认是否收到新主发来的免费 ARP
若看到 MAC 未变、状态为 STALE/FAILED，且没抓到新免费 ARP，就基本锁定是 ARP 同步缺失。
生产环境推荐的修复与预防措施
不依赖“等它自己老化”，而是主动干预：
- 在 Keepalived 的 notify script 中加入清理动作：例如主升为 MASTER 后，执行 arping -U -c 3 -I eth0
多发几次免费 ARP，提高到达率 - 对关键业务服务器，配置定时任务每 5 分钟执行 ip neigh flush to
，强制刷新 - 避免全局清 ARP（如
ip neigh flush all），防止影响其他服务；优先精准清理 VIP 相关条目 - 内核参数可微调（非必须）：
net.ipv4.neigh.eth0.base_reachable_time_ms=15000缩短 REACHABLE 基准时长，加快自然老化
本质上，Keepalived 解决的是 VIP 归属，而 ARP 缓存同步是配套动作。忽略后者，高可用就只完成了一半。
