ip_hash的核心是用客户端真实ip做哈希计算并固定映射后端服务器；ipv4取前3字节、ipv6用完整地址哈希后对服务器数取模，要求ip真实、upstream稳定、网络可控，否则易导致会话漂移或负载倾斜。
ip_hash 的核心是用客户端真实 IP 做哈希计算，再固定映射到某台后端服务器。它不依赖 cookie、不改应用逻辑，也不需要额外模块，但前提是 IP 真实、后端列表稳定、网络环境可控。
IP 地址怎么参与哈希运算
IPv4 地址只取前三个字节（如 192.168.1.x → 视为 192.168.1），再做哈希；IPv6 则使用完整地址或前 64 位。哈希结果对后端服务器总数取模，决定最终路由目标。这意味着：
- 同一局域网内大量用户（如 192.168.1.100 和 192.168.1.254）会被算作“同一个 IP”，全打到一台后端
- 只要 IP 不变、upstream 中 server 顺序和数量不变，映射关系就稳定
- 不支持 weight、backup 或 down 标记以外的任何修饰——加了就会启动失败
真实 IP 是前提，否则全乱套
如果请求经过 CDN、WAF、NAT 出口或公司代理，$remote_addr 就是上一跳地址，所有用户哈希值一样，全部挤向同一台后端。必须配合真实 IP 还原机制：
- 在 http 块中配置 set_real_ip_from，声明可信代理网段（如 10.0.0.0/8、192.168.0.0/16）
- 用 real_ip_header X-Forwarded-For 指定从哪个 HTTP 头读取原始 IP
- 在 location 中透传头信息：proxy_set_header X-Real-IP $remote_addr 和 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for
哪些操作会让会话突然“漂移”
ip_hash 映射不是永久绑定，以下任一变动都会触发全量重散列，导致大量用户请求跳转到不同后端：
- upstream 中新增或下线 server
- 调整 server 行顺序（哪怕只是换行或注释位置）
- 某台 server 被标记为 down，Nginx 会剔除它，但剩余节点的哈希索引整体偏移
- IPv4 用户在 NAT 环境下频繁更换出口 IP（比如手机切 WiFi/4G）
它适合什么场景，又不适合什么
ip_hash 是轻量级方案，不是通用解。适用条件很具体：
- 内网访问，客户端 IP 固定且唯一（如企业 OA、内部管理系统）
- 后端服务尚未改造为无状态，购物车或登录态暂存在内存中
- 没有统一 session 存储，又不想引入第三方模块
明显不适用的情况包括：面向公网的电商网站、大量移动用户、使用 CDN 的业务、后端需弹性扩缩容的系统。这类场景更推荐 sticky cookie 或 Nginx Plus 的 sticky learn。
