ip_hash策略在局域网中会导致严重负载倾斜和会话混乱，因其将共享出口ip的大量用户视为单一客户端；应改用cookie哈希、least_conn配合redis共享会话，或结合geo指令分类处理。
Nginx 的 ip_hash 策略在局域网（LAN）内大量并发请求时，容易出现严重负载倾斜甚至会话混乱，根本原因在于它把整个局域网出口 IP 当作“单一客户端”来处理。
局域网用户共享同一个出口 IP
企业、学校、运营商 NAT 环境下，成百上千终端设备通过同一台路由器或防火墙上网，Nginx 收到的 $remote_addr 全是那个出口公网 IP（比如 203.101.5.8）。ip_hash 对这个 IP 哈希后，只会固定映射到 upstream 中某一台后端服务器——所有局域网用户流量全打过去，其余节点几乎空闲。
后果很直接
- 单台后端服务器瞬间过载，响应延迟飙升甚至超时
- 其他服务器资源闲置，负载严重不均
- 登录态、购物车等依赖会话的业务，在不同用户间可能相互覆盖（因 Session 存于内存且未共享）
- 无法体现真实用户粒度，彻底失去“会话保持”的业务意义
常见但无效的应对方式
- 试图用
X-Forwarded-For替代$remote_addr：若上游没有正确透传或伪造风险高，反而引入安全隐患 - 在 Nginx 前加一层代理再做 hash：增加架构复杂度，且不能解决 NAT 下真实 IP 不可见的本质问题
更务实的解法
- ✅ 改用
hash $cookie_session_id consistent;：让应用在首次响应中 Set-Cookie，后续凭 Cookie 哈希分发，可精准识别用户 - ✅ 启用
least_conn或加权轮询 + 外部 Session 共享（如 Redis）：放弃客户端绑定，靠状态集中化保障会话一致性 - ✅ 对必须用 IP 的场景，结合
geo指令预分类局域网段，再为不同段配置独立 upstream 和 hash 规则（适合有明确出口 IP 池的政企环境） - ✅ 在应用层做轻量级 token 路由：登录后下发短期有效路由标识，Nginx 用
hash $arg_route_key分发
ip_hash 本质不是为局域网设计的。它只在公网直连、IP 稳定且一一对应的场景下才真正可靠。
