ip hash 通过哈希客户端真实 ip（ipv4 取前3段、ipv6 用完整地址或前64位）并对可用后端数取模，固定路由请求；但依赖 ip 稳定、upstream 不变及真实 ip 可还原，否则易会话漂移或负载倾斜，推荐改用 cookie 哈希或 redis 共享 session。
IP Hash 是 Nginx 提供的一种轻量级会话保持方案，它不依赖外部存储或应用改造，靠哈希客户端真实 IP 把请求“钉”在某台后端上。但它的稳定性非常脆弱——只要 IP 不稳、后端一动、代理一挡，会话就可能断开或倾斜。
IP Hash 怎么固定请求路由
它对客户端 IPv4 地址只取前 3 段（例如 192.168.1.x 全部视为同一 IP），IPv6 则用完整地址或前 64 位做哈希，再对当前可用后端数量取模，结果唯一对应一台服务器。
- 映射关系只在 IP 不变、upstream 中 server 顺序和数量不变时才稳定
- 不支持 weight、backup、down 以外的修饰符，加了会导致 Nginx 启动失败
- 仅适用于 HTTP upstream；TCP/UDP 四层转发需改用 stream 模块 + hash $remote_addr consistent
真实 IP 必须能还原出来
如果请求经过 CDN、WAF、NAT 或公司代理，$remote_addr 就是代理地址，所有用户会被哈希到同一台后端，完全失效。
- 在 http 块中声明可信网段：set_real_ip_from 10.0.0.0/8;（按实际代理 IP 段填写）
- 指定头字段：real_ip_header X-Forwarded-For;
- 在 proxy_pass 的 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，剩余节点哈希索引整体偏移
- 用户从 4G 切换到 WiFi，IP 改变，原 Session 找不到
比 IP Hash 更靠谱的替代方向
业务稍具规模或稳定性要求提高时，建议逐步迁移：
- Cookie 哈希：用 hash $cookie_session_id，基于后端生成的标准会话 Cookie 路由，抗代理、NAT 和 IP 变更
- Redis 共享 Session：应用层把 Session 存到 Redis，所有后端共用一套状态，彻底解耦路由与会话
- 搭配健康检查与自动剔除机制，避免单点宕机导致会话丢失
