ip_hash导致流量倾斜的主因是客户端真实IP识别错误，需通过set_real_ip_from等指令修复IP来源；替代方案包括cookie粘性会话、无状态session设计或least_conn负载均衡。
ip_hash 是 Nginx 中一种基于客户端 IP 做哈希映射的会话保持方式，但它本身不是为“负载均衡均匀性”设计的。配置错误或使用场景不当，确实会导致后端流量严重倾斜——比如 80% 请求落到某一台 server 上，其余节点空闲。问题根源往往不在 hash 算法本身，而在 IP 特征、网络架构或配置细节。
确认是否真由 ip_hash 引起不均
先排除其他干扰因素：
- 用 access_log 配合
$remote_addr和$upstream_addr记录每条请求实际转发到哪台后端，采样 1000+ 请求后统计分布（别只看后台 CPU 或连接数） - 检查客户端真实 IP 是否被代理污染：若前端有 CDN、WAF 或 LVS，
$remote_addr可能是中间节点 IP（如全是 10.0.0.x），导致大量请求哈希到同一值 - 确认是否启用了 proxy_set_header X-Real-IP $remote_addr; 却没配合 set_real_ip_from + real_ip_header X-Forwarded-For;，致使 ip_hash 实际作用在伪造 IP 上
修复 IP 来源识别（关键一步）
ip_hash 生效的前提是哈希对象是真实的客户端公网 IP。常见修复写法：
set_real_ip_from 192.168.10.0/24; # 你的可信代理网段（如 nginx 前还有 haproxy） set_real_ip_from 203.0.113.5; # 单个可信 LB IP real_ip_header X-Forwarded-For; real_ip_recursive on;
然后在 upstream 块中继续使用 ip_hash —— 此时它将基于 $remote_addr（已被重写为真实客户端 IP）计算哈希值。
⚠️ 注意：不要在 ip_hash 同时启用 hash $http_x_forwarded_for consistent;，二者冲突且后者不兼容 ip_hash。
评估是否真需要 ip_hash
很多场景下，ip_hash 是“伪会话保持”：IPv4 地址复用（如 NAT 网关后千人共用一个出口 IP）、IPv6 / 移动网络频繁换 IP，都会导致会话漂移或压垮单节点。更稳的替代方案包括：
-
基于 Cookie 的 sticky session：用
sticky cookie srv_id expires=1h domain=.example.com path=/;（需 nginx-plus；开源版可用第三方模块 likenginx-sticky-module-ng） - 应用层 token + 无状态设计：让后端服务共享 session 存储（Redis），前端完全不依赖绑定节点
- least_conn 或 random with two least_conn：对长连接或响应时间差异大的服务更公平
调优 ip_hash 的补充技巧
如果必须坚持用 ip_hash（例如老系统强依赖源 IP 绑定），可尝试以下缓解措施：
- 开启 upstream 的 keepalive，减少新建连接带来的哈希抖动
- 避免在 upstream 中动态增减 server（ip_hash 哈希空间随 server 数量变化，会导致已有连接重散列）
- 对 IPv4 使用
ip_hash;，对 IPv6 客户端单独配置hash $binary_remote_addr consistent;（需 nginx ≥ 1.11.0），因 IPv6 地址哈希分布更稀疏 - 用
weight手动微调各节点承载比例（如server 10.0.1.10:80 weight=3;），但不能解决根本分布逻辑缺陷
ip_hash 不是万能会话方案，流量不均往往是信号灯——提醒你该检查链路中的真实 IP 传递是否可靠，或者重新思考会话保持的设计边界。定位清楚源头，比反复调整 weight 更有效。
