ip hash 机制通过哈希客户端真实ip并取模映射后端实现会话粘滞，但依赖ip稳定与upstream不变；移动网络切换、nat复用、代理覆盖及后端变更均会导致会话丢失或负载倾斜，推荐改用cookie哈希或redis共享session。
IP Hash 机制通过将客户端真实 IP 地址哈希后固定映射到某台后端服务器，让同一用户的请求始终落到同一节点，从而避免因轮询导致的 Session 丢失。它不依赖外部存储或应用改造，适合快速兜底，但效果高度依赖 IP 稳定性和后端列表一致性。
IP Hash 的工作原理
它对客户端 IPv4 地址取前 3 段（如 192.168.1.x 全部视为同一 IP），或整个 IPv6 地址做哈希运算，再对当前可用后端数量取模，结果唯一对应一台服务器。只要用户 IP 不变、upstream 中 server 顺序和数量不变，路由就稳定。
- 哈希源默认是 $remote_addr，即 Nginx 直接收到的源地址
- 仅适用于 HTTP upstream；TCP/UDP 四层转发需用 stream 模块配合 hash $remote_addr consistent
- 不支持 weight、backup、down 等参数，加了会导致 Nginx 启动失败
真实 IP 必须可还原
前端若存在 CDN、WAF 或多层代理，$remote_addr 就是代理地址，所有请求会被哈希到同一台后端，完全失效。必须启用 real_ip_module 还原原始 IP：
- 在 http 块中声明可信网段：set_real_ip_from 10.0.0.0/8;、set_real_ip_from 192.168.0.0/16;
- 指定头字段：real_ip_header X-Forwarded-For;
- 在 proxy_pass 的 location 中透传：proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
常见失效场景与应对
IP Hash 表面简单，但几个硬性限制容易导致“配了没用”：
- NAT 环境下 IP 复用：内网多个用户共用一个出口 IP，全被分到同一台后端，造成负载倾斜
- 后端变更触发重散列：新增、删除或临时标记某台 server 为 down，剩余节点重新分配哈希槽位，大量用户会话“漂移”
- 移动网络切换：用户从 4G 切 WiFi，IP 改变，Session 断开——这不是配置问题，而是架构局限
比 IP Hash 更稳的替代方案
当业务规模扩大或稳定性要求提高时，建议逐步升级：
- Cookie 哈希：用 hash $cookie_JSESSIONID consistent;，基于后端生成的标准会话 Cookie 路由，抗代理、NAT 和 IP 变更
- Redis 统一存储 Session：后端将 Session 写入共享 Redis，彻底解耦路由逻辑与状态存储
- Sticky Cookie（Nginx Plus 或第三方模块）：由 Nginx 下发路由标识 cookie，首次请求自动绑定，无需后端参与
