ip_hash机制核心是会话保持而非提升并发，通过哈希客户端IP实现请求绑定同一后端，适用于未实现Session共享的临时场景，但存在NAT下负载倾斜、IP变更会话中断、扩缩容重散列及IPv6不支持等风险。
Nginx 的 ip_hash 机制在大并发场景下不是为扛高并发而设计的，而是为会话保持服务的。它本身不提升吞吐量，反而可能加剧后端压力不均，需结合实际架构审慎使用。
ip_hash 的核心作用是“绑定”，不是“分流”
它通过哈希客户端 IP（默认 $remote_addr）决定请求转发到哪台后端，目标是让同一 IP 的请求始终落到同一台机器上。这在以下情况有实用价值：
- 后端尚未实现 Session 共享（如没接 Redis 存储 session）
- 短期内无法改造鉴权逻辑（如仍依赖内存中的 JSESSIONID）
- 内网固定办公环境、IP 变化极少的场景
但它解决的是“登录态一致性”问题，而非“并发承载能力”问题。
大并发下用 ip_hash 的典型风险
- IP 集中导致雪崩：校园网、企业 NAT、移动网络出口常有成百上千用户共用一个公网 IP，所有请求被 hash 到同一台后端，瞬间压垮单节点。
- IP 变更频繁中断会话：用户切 WiFi/4G、使用动态 IP 的宽带，hash 值变化，登录态丢失，体验断层。
- 扩缩容引发大面积重散列：增减一台后端服务器，整个哈希环重排，大量用户被重新分配，Session 失效。
-
IPv6 不支持原生 hash：
ip_hash仅处理 IPv4；若用户走 IPv6，Nginx 会 fallback 到轮询，破坏会话一致性。
示例：某电商 App 在促销日遭遇 3 万 QPS，其中 60% 用户来自三大运营商的 CGNAT 地址池，结果 3 台后端中 2 台 CPU 持续 98%，1 台空闲——正是
ip_hash导致流量严重倾斜。
更适合大并发的替代方案
无状态 Token 鉴权（推荐）
前端存 JWT，后端校验签名并解析 payload，完全不依赖服务端存储，天然适配任意负载均衡策略。统一 Session 存储
Spring Session + Redis / Tomcat RedisSessionManager，把 session 外置，轮询或 least_conn 都可自由使用。Cookie Hash（比 ip_hash 更稳）
hash $cookie_jsessionid consistent;—— 依赖浏览器 Cookie，只要用户没清缓存，就能保持粘性，且不受 NAT 和 IP 变更影响。-
配合健康检查与自动剔除
即使用了ip_hash，也务必启用：upstream backend { ip_hash; server 192.168.1.100:8080 max_fails=3 fail_timeout=30s; server 192.168.1.101:8080 max_fails=3 fail_timeout=30s; }避免故障节点持续接收流量。
不复杂但容易忽略。
