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 缓存同步是配套动作。忽略后者，高可用就只完成了一半。