Nginx 下双机热备主从切换对长连接会话的影响

主从切换不会中断连接但导致长连接失效，因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 :端口，确认新连接已建立且旧连接未残留