ip_hash是Nginx原生会话保持机制，需正确配置upstream、还原真实IP并警惕漂移风险；推荐Cookie哈希、Redis共享Session或stream模块hash替代。
ip_hash 是 Nginx 原生支持的会话保持方式，核心是把同一客户端的真实 IP 映射到固定后端，不需要改应用、不依赖外部存储。但它不是“配了就稳”，关键得让哈希依据可靠、后端列表稳定、IP 不被误判。
必须写对 upstream 配置
ip_hash 必须放在 upstream 块第一行，顶格写，不能缩进，不能和 weight、backup、down 等参数共存，否则 Nginx 启动直接失败：
- upstream 至少要定义两台后端（单节点不生效）
- server 行只写 IP:PORT，不要加 http:// 或路径
- IPv4 地址只取前三个字节哈希（例如 192.168.1.100 和 192.168.1.255 视为同一个 IP）
必须还原真实客户端 IP
如果请求经过 CDN、WAF、公司代理或 NAT 设备，$remote_addr 默认是上一跳地址，所有用户会被哈希到同一台后端，ip_hash 彻底失效。需配合 real_ip_module：
- 在 http 块中声明可信代理网段：set_real_ip_from 10.0.0.0/8;（按实际代理 IP 段调整）
- 指定真实 IP 来源头：real_ip_header X-Forwarded-For;
- 在 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，剩余节点数量改变，哈希结果整体偏移
- 用户从移动网络切换 WiFi，IP 变更，原会话在新后端找不到
- 内网大量设备经同一 NAT 出口，前三段 IP 相同，全部打到同一台后端造成过载
比 ip_hash 更稳的替代方案
当业务规模上升、公网用户增多、或频繁扩缩容时，建议逐步迁移：
- Cookie 哈希：用 hash $cookie_JSESSIONID consistent;，基于后端返回的标准会话 Cookie 路由，天然抗代理和 IP 变更
- Redis 共享 Session：后端统一把 session 存入 Redis，所有节点读写同一份状态，彻底解耦路由与会话逻辑
- 四层场景用 stream 模块：TCP/UDP 流量（如 MySQL、Redis 代理）不支持 ip_hash，需改用 hash $remote_addr consistent; 配合 stream {} 块
