ipvsadm -ln --stats 显示的是内核 ipvs 模块实时统计的连接分布，重点看 conns（已调度连接数）和 pps（每秒包数），若某 realserver 的 conns 持续超其他节点 3 倍且 1 分钟不回落，表明调度异常；常见原因包括 wlc 权重设错、健康检查后连接未回收、dr 模式下 arp 配置错误导致流量绕过调度器。
ipvsadm -ln --stats 看连接数是否真不均
别光看 ipvsadm -L 的规则列表，那只是静态配置；真正决定流量去向的是内核 IPVS 模块实时统计的连接分布。执行 ipvsadm -ln --stats，重点盯 Conns（当前连接数）和 PPS（每秒包数）两列，按 realserver 排序后对比差异。如果某台 Conns 是其他节点的 3 倍以上，且持续 1 分钟不回落，基本可以确认不是瞬时抖动，而是调度逻辑出了问题。
常见误判点：没关掉健康检查临时剔除节点，导致流量被强制压到剩余节点；或者某台 RS 刚恢复，IPVS 还没来得及把历史连接数清零，Conns 滞留虚高。
wlc 算法下 weight 设错是最大元凶
wlc（加权最小连接）公式是 (active_conn × 256 + inactive_conn) / weight，它默认把 weight 当作服务器处理能力的倒数。但很多人直接按 CPU 核数设 weight=8、weight=4，结果发现 8 核机器反而分得更少——因为它的响应延迟高、连接堆积快，实际分母变大了。
- 真实权重应基于压测或历史负载反推：比如某台 Redis 平均延迟比其他高 30%，
weight就不该设 10，而该设 6～7 - 检查当前权重：用
ipvsadm -ln看输出中Weight列，确认是否和配置一致 - 临时调权验证：执行
ipvsadm -e -t VIP:PORT -r RIP:PORT -w 3降低嫌疑节点权重，观察Conns是否快速下降
DR 模式下 ARP 配置错误会导致“假均衡”
在 DR 模式中，如果某台 RS 没正确设置 arp_ignore=1 和 arp_announce=2，它可能在后台偷偷响应 VIP 的 ARP 请求，导致部分客户端把后续请求直接发给它，绕过 LVS 调度器。这时 ipvsadm 统计看起来“均衡”，但真实流量已经分裂——一台在 IPVS 表里接活，另一台靠 ARP 抢到了直连流量。
验证方法：
- 在每台 RS 上执行
sysctl net.ipv4.conf.all.arp_ignore和sysctl net.ipv4.conf.lo.arp_ignore，必须都为1 - 执行
arp -an | grep VIP，确保只有调度器 MAC 地址对应 VIP，RS 上不能有该条目 - 抓包确认：
tcpdump -i any host VIP and arp，看是否有 RS 主动发送 ARP Reply
健康检查失败后连接未及时回收
Keepalived 的 TCP_CHECK 或 HTTP_GET 失败后，会把 realserver 状态标为 Inactive，但已建立的长连接不会自动断开。如果这台 RS 实际已卡死（比如 Java 应用 OOM 后拒绝新请求但 TCP 连接还 hang 在那里），IPVS 仍会把新请求继续分发过去，而旧连接又无法释放，最终形成“连接数暴涨却无响应”的假象。
应对方式：
- 缩短健康检查超时：
connect_timeout 3、retry 2，避免长时间误判 - 配合内核参数：
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout加速异常连接回收 - 写个巡检脚本定期执行
ss -tn state established '( dport = :PORT )' | wc -l，对连接数异常高的 RS 主动踢出
