ip_hash不解决IP冲突，仅机械哈希分配；NAT/CDN导致多用户共用IP时，所有请求均落到同一后端，需通过还原真实IP、改用cookie哈希或限流等手段缓解。
IP Hash 本身不处理客户端 IP 冲突，它只是按规则哈希分配——冲突问题（比如大量用户共用一个出口 IP）是现实网络结构带来的，Nginx 不会主动“解决”，只能靠配置规避或换策略应对。
为什么会出现客户端 IP 冲突
所谓“IP 冲突”，实际是指多个真实用户被识别为同一个客户端 IP，常见于：
- 企业内网或校园网通过统一 NAT 网关上网，成百上千人共享一个公网出口 IP
- 移动运营商使用大规模 CGNAT，几十万用户可能落在同一段公网 IP 下
- 用户经过 CDN、LVS 或多层反向代理，且未正确透传真实 IP，导致 $remote_addr 是中间节点地址
ip_hash 对冲突的默认行为
它不做区分、不作合并判断，只机械执行哈希逻辑：
- IPv4 地址取前 3 段（如 192.168.1.x → 统一视为 192.168.1.0）参与计算，进一步放大内网用户集中倾向
- 所有来自该 IP 段的请求，哈希结果完全一致，全部落到同一台后端
- 没有负载再平衡机制——哪怕那台机器已过载，只要它“可用”，流量就不会自动分流
缓解 IP 冲突的实际办法
不能靠 ip_hash 自身修正，需组合其他手段降低影响：
- 优先还原真实 IP：在 proxy_pass 前配置 set_real_ip_from 和 real_ip_header，确保哈希基于 $remote_addr 的是用户真实地址，而非 CDN 或 LB 的 IP
- 改用更细粒度的 hash 键：比如 hash $http_x_forwarded_for consistent;（需前端透传可信 X-Forwarded-For）或 hash $cookie_session_id;，把粘性锚点从 IP 挪到用户级标识上
- 限制单 IP 并发或速率：用 limit_conn / limit_req 控制来自同一 IP 的连接数或请求数，防止单点压垮后端
- 监控并识别倾斜：在日志中加入 $upstream_addr 和 $remote_addr，定期统计各后端接收的 IP 段分布，发现集中访问及时干预
什么情况下应放弃 ip_hash
当以下任一情况明显存在时，ip_hash 就不再适用：
- 业务面向移动用户或大型政企客户（NAT 率高）
- 后端需频繁扩缩容，无法接受哈希重散列导致的会话中断
- 要求严格负载均衡，而非仅会话保持
- 已具备分布式 Session 存储（如 Redis），可直接改用轮询 + session 共享
不复杂但容易忽略。
