主从切换不会中断连接但导致长连接失效，因TCP状态无法随VIP漂移迁移，旧节点停止响应、新Master无conntrack记录而丢包或RST，本质是VRRP与TCP状态机的根本矛盾。
主从切换本身不会“中断”连接，但会直接导致长连接失效——因为 TCP 连接状态无法随 VIP 漂移而迁移，客户端仍在向旧节点发包，而新 Master 并不知道这些连接的存在。
为什么长连接会在切换瞬间断开
Linux 内核不维护跨节点的连接状态。VIP 从原 Master 解绑后，该节点不再响应对应 IP 的 SYN/ACK，也不处理已有连接的 ACK 和数据包；新 Master 虽然绑定了同一 VIP，但内核 conntrack 表里没有这些连接记录，收到数据包后只能丢弃或 RST。这不是配置错误，而是 VRRP 协议与 TCP 状态机的根本矛盾。
典型表现包括：
- WebSocket 触发
onclose，event.code = 1006（abnormal closure） - HTTP/1.1 长轮询流式响应中断，浏览器重连但丢失
Last-Event-ID - gRPC over HTTP/2 连接被 RST，客户端报
unavailable: io exception - 用户仍持有有效 Session Cookie，但请求持续超时或返回 502/504
关键影响环节与默认行为
切换过程中的三个关键延迟点共同放大了影响：
-
VRRP 检测延迟：默认
advert_int 1+fail_check 3→ 最长 4 秒才触发升主 - ARP 缓存未刷新：下游交换机、网关或客户端仍把 VIP 解析为旧 MAC，新请求继续发往故障节点
- 连接跟踪缺失：Keepalived 不同步 conntrack 表，新 Master 对已有连接完全“不可见”
缓解长连接闪断的实操要点
服务端和客户端需协同优化，不能只依赖 VIP 切换：
- 在
vrrp_instance中启用 GARP 主动通告：garp_master_refresh 5、garp_master_refresh_repeat 5 - 配合
notify_master脚本调用arping -c 5 -A -I eth0 VIP，强制刷新二层设备 ARP 表 - 将
advert_int降至 0.5，fail_check设为 2，缩短检测窗口 - 服务端开启 TCP keepalive：
net.ipv4.tcp_keepalive_time=30、tcp_keepalive_intvl=10、tcp_keepalive_probes=3，约 60 秒内可探测断连 - 客户端 SDK 必须实现幂等重试，对连接拒绝、502/504 错误自动重发，建议加入 100–500ms 随机退避
验证是否真正生效
仅检查 VIP 是否绑定毫无意义，必须验证端到端连接可用性：
- 在客户端侧部署轻量探测：
curl -m 3 -s -o /dev/null -w "%{http_code}\n" http://VIP/api/health，每 5 秒执行一次 - 切换瞬间抓包确认：
tcpdump -i eth0 -nn "host VIP and (tcp or arp or proto 112)"，看 GARP 是否发出、首个 SYN 是否抵达新 Master - 登录新 Master 执行
ss -tn state established | grep :端口，确认新连接已建立且旧连接未残留
