ip_hash通过哈希客户端真实IP并取模映射实现会话保持，IPv4取前三字节、IPv6用完整地址，需真实IP且upstream列表稳定；不支持weight、易受NAT和IP变更影响。
ip_hash 通过哈希客户端真实 IP 地址并固定映射到某台后端服务器来实现“同一客户端始终访问同一节点”。它不依赖 Cookie、Session 存储或额外模块，而是靠 Nginx 内置的确定性哈希算法完成绑定。
ip_hash 的映射逻辑
它对客户端源 IP 做哈希运算：
- IPv4 地址只取前三个字节（例如 192.168.1.x 全部视为同一组输入），降低 NAT 环境下的过度分散
- IPv6 使用完整地址参与哈希，保证精度
- 哈希结果对当前 upstream 中可用服务器数量取模，得出固定下标，从而选定目标 server
- 只要客户端 IP 不变、后端列表没增删或重排，这个下标就稳定不变
必须确保用的是真实客户端 IP
如果请求经过 CDN、LVS 或前置代理，$remote_addr 默认拿到的是代理节点的 IP，会导致所有用户被哈希成同一个值。需配合以下配置还原真实 IP：
- 在 http 或 upstream 上方启用 real_ip_module
- 用 set_real_ip_from 明确声明可信代理网段（如 10.0.0.0/8）
- 用 real_ip_header X-Forwarded-For 或 X-Real-IP 指定头字段提取原始地址
哪些操作会破坏固定映射
ip_hash 的稳定性高度依赖 upstream 配置的静态性，以下变更会触发全量重散列，导致大量用户“跳节点”：
- 新增或删除一台 server（哪怕只是临时注释掉一行）
- 调整 server 行顺序（如把第二行移到第一行）
- 某台 server 被标记为 down 或因健康检查失败被自动剔除
- 在 ip_hash 同一 upstream 块中混用 weight、backup 等参数（Nginx 会直接报错或忽略）
适用与不适用场景
适合快速落地会话保持，但有明显边界：
- ✅ 内网环境（IP 稳定、无 NAT）、老系统无法改造、购物车存在内存中
- ✅ 登录态未统一的短时过渡方案
- ❌ 大量用户共用出口 IP（如企业宽带、校园网），会造成单节点过载
- ❌ 移动端频繁切换网络（Wi-Fi → 4G → 切换基站），IP 变更即会话中断
- ❌ 需要按机器性能分配流量（ip_hash 不支持 weight）
