加权轮询是按权重比例分配请求的负载均衡算法，不导致客户端IP漂移；IP漂移由keepalived+VIP故障切换引起，二者机制独立，需分别排查。
加权轮询本身不会导致客户端IP漂移——IP漂移是高可用架构中由 keepalived + VIP 引起的网络层行为，和负载均衡算法无关。如果你观察到“客户端IP在加权轮询下发生漂移”，实际是混淆了两个独立机制：一个是请求分发策略（如 weight 配置），另一个是虚拟IP故障切换（VIP 漂移）。排查要从这两条线分开入手。
确认是否真发生了IP漂移
先明确现象本质：
- 如果访问的是同一个域名或 VIP 地址，但后端日志中
$remote_addr突然从 192.168.1.10 变成 192.168.1.11，这不是 IP 漂移，而是 Nginx 正常转发——此时你看到的是后端服务器的真实 IP，不是客户端 IP； - 真正的 IP 漂移指：客户端原本通过 VIP 10.0.0.100 访问 Nginx，某时刻该 VIP 突然从主节点移到备节点，导致 TCP 连接中断、SSL 重协商、甚至 DNS 缓存未刷新引发短暂不可达；
- 加权轮询只影响
upstream内部哪台后端机器处理请求，不改变 Nginx 实例本身的入口地址或网络归属。
检查 Nginx 日志中的真实客户端 IP
加权轮询配置正确时，所有后端服务应统一拿到真实的客户端 IP，否则会误判为“IP 不稳定”：
- 确保 Nginx 的
proxy_set_header X-Real-IP $remote_addr;和X-Forwarded-For正确透传； - 后端应用（如 Flask/Django/Node）必须读取
X-Real-IP或X-Forwarded-For头，而不是直接用 socket 远程地址； - 如果后端日志里
X-Real-IP字段频繁变化（比如同一用户两次请求出现不同值），说明前端有代理链（如 CDN、WAF、多层 Nginx）未正确配置real_ip_recursive on和set_real_ip_from。
验证加权轮询是否按预期生效
避免把“权重分配不均”误认为“IP 漂移”：
- 用
ab -n 600 -c 100 http://your-domain/发起批量请求，再查 Nginx access log 中每台后端的命中次数； - 若配置
weight=3、weight=2、weight=1，理论占比应接近 50% / 33% / 17%，而非严格 3:2:1 的单次循环（Nginx 使用平滑加权轮询，会动态调整）； - 注意：健康检查失败的节点会被临时剔除，也会造成权重比例短期失真，需同步检查
upstream的max_fails和fail_timeout设置。
排查 keepalived VIP 漂移是否被误读为“客户端IP漂移”
如果你用了双机热备，这才是 IP 漂移的真正源头：
- 登录两台 Nginx 服务器，执行
ip addr | grep "inet.*virtual"，看 VIP 是否在主节点上； - 检查 keepalived 日志（通常在
/var/log/messages或journalctl -u keepalived），搜索Transition to MASTER或FAULT； - 常见诱因：主节点网卡故障、心跳线丢包、vrrp_script 脚本返回非零、systemd 服务异常重启；
- 只要 VIP 切换发生，客户端新建连接就会连到新主机，旧连接中断——这跟加权轮询完全无关，但表象可能被误解为“IP 不稳定”。
