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 生效：

Obsidian (Linux)

操作 Obsidian 库（纯 Markdown 笔记），并通过 notesmd-cli 实现自动化。

下载

• 确保 $remote_addr 是真实用户 IP：若前端有 CDN 或代理，需启用 real_ip_module，配置 set_real_ip_from 和 real_ip_header X-Forwarded-For
• upstream 示例：

upstream backend {
  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 集中效应严重）