ip_hash与weight冲突是架构层面禁止：ip_hash要求强确定性映射，weight依赖概率性调度，二者逻辑互斥；混用会报“ip_hash cannot be used with weighted servers”并启动失败，唯一兼容解法是改用hash $remote_addr consistent配合weight。
直接禁用 ip_hash，改用 hash $remote_addr consistent，这是唯一兼容 weight 的标准解法。
为什么 ip_hash 和 weight 会冲突
ip_hash 的设计目标是强确定性：同一客户端 IP 必须始终落到同一台后端，不考虑节点性能差异；weight 则服务于轮询类算法，依赖概率性调度来按比例分配流量。两者在 Nginx 内部调度路径上互斥，不是配置疏忽，而是架构层面明确禁止。
- 只要 upstream 块中同时存在
ip_hash;和任意server ... weight=...，Nginx 启动或重载就会报错，典型提示为：
“ip_hash cannot be used with weighted servers” 或 “ip_hash and weight cannot be used together” - 即使配置侥幸通过（如部分旧版本仅警告），weight 参数也会被完全忽略，实际流量仍按纯哈希分发，容易引发误判
- ip_hash 对 IPv4 仅取前三个八位组（例如 192.168.1.x 全视为相同输入），进一步加剧负载倾斜，与权重无关但常被混淆
正确替代方案：hash + consistent + weight
用 hash $remote_addr consistent; 替代 ip_hash;，即可保留 IP 级别粘性，又让 weight 生效：
- 确保
$remote_addr是真实用户 IP：若前端有 CDN 或代理，需启用real_ip_module，配置set_real_ip_from和real_ip_header X-Forwarded-For - upstream 示例：
hash $remote_addr consistent;
server 10.0.0.1:8080 weight=3;
server 10.0.0.2:8080 weight=1;
}
- 该方案要求 Nginx ≥ 1.7.2，一致性哈希还能显著减少后端增减时的请求漂移
排查是否真被冲突影响
不要只看主配置文件，注意隐式引入：
- 检查所有
include进来的子配置，可能某处悄悄写了weight - 确认未启用第三方模块（如某些商业 LB 模块）引入了隐式权重逻辑
- 查看 Nginx 错误日志（
error_log）——启动失败时第一条报错通常就是冲突提示 - 用
nginx -t测试配置，它会准确定位到出问题的行号
什么情况下不该用 ip_hash
即使没冲突，ip_hash 本身也有明显局限，业务若存在以下情况，应主动放弃：
- 面向大量移动用户或政企客户（CGNAT 导致成千上万用户共享一个出口 IP）
- 后端需频繁扩缩容，无法接受节点变更引发的大面积会话中断
- 已使用 Redis 或数据库集中管理 Session，不再依赖服务端本地状态
- 日志中观察到某台后端长期承接远超平均值的 IP 段请求（说明 NAT 集中效应严重）
