ip_hash在局域网出口ip场景必然导致严重负载倾斜，因其算法边界限制无法区分共享nat用户；应改用hash $cookie_route consistent、redis共享session或jwt无状态认证等更稳定策略。
直接用 ip_hash 处理局域网出口 IP（比如企业、校园、运营商 NAT）必然导致严重倾斜——成百上千用户被哈希到同一台后端，这不是配置问题，而是算法边界限制。解决方向不是调参，而是换策略或补维度。
改用一致性哈希 + 更稳定标识
保留“请求路由稳定”目标，但放弃单靠 IP 的脆弱假设：
- 优先用
hash $cookie_ROUTE consistent：后端登录成功时下发ROUTECookie，Nginx 据此路由；用户不清 Cookie 就不会漂移，节点增减影响也最小 - 若无法改后端，可用组合字段哈希，例如
hash $remote_addr$http_user_agent consistent，把浏览器指纹加入哈希因子，大幅降低同 IP 下的碰撞率 - 避免用
hash $remote_addr（无consistent），它和ip_hash一样受节点变动影响，70% 用户会重新分配
彻底脱离 IP，走无状态会话
当大量流量来自共享出口时，IP 已失去用户区分意义，强绑 IP 反而制造瓶颈：
- 后端统一用 Redis 存 Session，前端传
sessionId或 JWT Token，Nginx 改用least_conn或加权轮询，天然抗倾斜 - JWT 场景下连 Session 存储都省了，校验逻辑前置到 Nginx（用
auth_request模块），负载完全均匀 - 灰度或路由需求可改用请求头，比如解析
X-User-ID或X-Tenant做map分发，比 IP 稳定得多
实在要保 ip_hash，必须做两件事
仅限内部办公网、固定设备等可控场景，且需严格满足：
- 确认
$remote_addr是真实终端 IP：启用real_ip_module，配全可信代理段（如set_real_ip_from 10.0.0.0/8;），并用日志验证还原效果 - 禁用所有动态扩缩容：upstream 列表锁死，不增不减；否则每次变更都会让多数用户会话丢失，登录态、本地缓存全失效
快速识别是否已倾斜
别只看配置，用日志验证实际分布：
- 统计访问日志中
$remote_addr前三段出现频次：awk '{print substr($1,1,index($1,".")-1)}' access.log | sort | uniq -c | sort -nr | head -5，如果前五名全是192.168、10.128这类内网前缀，且对应后端请求数远超均值，就是典型 NAT 倾斜 - 同时查
$upstream_addr分布，确认高请求量后端是否长期承担远超其他节点的流量（比如 3 倍以上持续数分钟）
