ip_hash 是 nginx 原生会话保持机制，通过哈希客户端真实 ip 将请求固定到后端服务器，适用于内网 ip 稳定的轻量场景，但非 session 共享方案，需严格配置 upstream、还原真实 ip 并避开 nat 和扩缩容导致的映射偏移。
ip_hash 是 Nginx 原生支持的会话保持机制，它不依赖外部存储，而是通过哈希客户端真实 IP，把请求“固定”到某台后端服务器上，让 Session 能自然命中。但它不是 Session 共享方案，本质是缓解 Session 丢失的临时策略——适合内网 IP 稳定、暂无 Redis 等共享存储能力的轻量级场景。
基础配置必须严格遵循的规则
看似一行就能启用，但错一个细节就等于没配：
- ip_hash 必须紧贴 upstream 块首行，不能缩进，也不能和 hash $cookie_jsessionid 等其他 hash 指令共存
- upstream 必须定义至少两台后端（不能只写 localhost 或单节点）
- server 行只写 IP:PORT，不加 http://、/path 或 protocol 字段
- 不支持 weight、backup、down 等参数；加了会导致 Nginx 启动失败
真实客户端 IP 必须可识别
如果前端有 CDN、WAF、Nginx 代理或多层负载均衡，$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;
- 指定真实 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;
避开常见失效陷阱
这些限制极易导致“配了等于没用”：
- IPv4 地址仅取前 3 段哈希（如 192.168.1.100 和 192.168.1.255 视为同一 IP），企业内网 NAT 出口下大量用户会集中打到一台机器
- 后端列表顺序或数量变动（如扩容、缩容、临时 down 掉一台），所有哈希映射整体偏移，用户 Session 大面积“漂移”
- 某台 server 标记为 down 时，Nginx 会剔除它，剩余节点重新分配请求，但原有 IP 映射关系仍在剩余节点上维持（这点常被误认为失效）
- 仅适用于 HTTP upstream；TCP/UDP 四层转发需改用 stream 模块 + hash $remote_addr consistent;
更稳的替代思路建议
当业务增长、公网用户增多或频繁扩缩容出现后，应逐步升级方案：
- 改用 Cookie 哈希：hash $cookie_JSESSIONID consistent;，抗代理、NAT 和 IP 变更干扰更强，首次无 Cookie 时走轮询，后续自动绑定
- 后端统一接入 Redis 存储 Session（如 Spring Boot 配 spring.session.store-type=redis），彻底解耦路由与状态
- 若无法改造后端，可用 sticky cookie（需 Nginx Plus 或第三方模块），由 Nginx 下发 srv_id 类 cookie 控制路由
