IP Hash 不是真正意义上的 Session 共享，而是通过请求绑定实现会话保持：对客户端 IPv4 前三段或完整 IPv6 地址哈希取模，固定路由至同一后端；需真实 IP 稳定、upstream 列表不变、无其他 hash 指令冲突，且前置代理时须用 real_ip_module 还原真实 IP，否则失效。
IP Hash 不是真正意义上的 Session 共享，而是通过“请求绑定”规避共享问题——它让同一 IP 的请求始终落到同一台后端服务器上，使 Session 自然留在那台机器上，从而避免反复登录。这方法轻量、无需额外组件，但适用前提明确，用错场景反而会放大问题。
IP Hash 的核心逻辑与生效条件
它对客户端 IPv4 地址取前 3 段（如 192.168.1.x → 192.168.1），或完整 IPv6 地址做哈希，再对当前可用 upstream server 数量取模，结果固定指向某一台。因此必须同时满足：
- 用户真实 IP 在整个请求链路中稳定不变
- upstream 块中的 server 列表顺序、数量、可用状态不频繁变动
- 没有其他 hash 指令（如 hash $cookie_jsessionid）与 ip_hash 共存
前端有代理时必须还原真实 IP
如果业务前置了 CDN、WAF 或多层 Nginx 反代，$remote_addr 默认拿到的是最后一跳代理的 IP，哈希就失效了。必须启用 real_ip_module：
- 用 set_real_ip_from 明确声明可信代理网段
- 用 real_ip_header 指定携带原始 IP 的请求头（通常是 X-Real-IP 或 X-Forwarded-For）
- 确保 proxy_set_header X-Real-IP $remote_addr 和 X-Forwarded-For $proxy_add_x_forwarded_for 在 location 中正确透传
配置写法与常见陷阱
ip_hash 必须紧贴 upstream 块第一行，顶格书写，不能缩进；也不能加 weight、backup、down 等参数，否则 Nginx 启动会报错。典型写法如下：
ip_hash;
server 10.0.1.10:8080;
server 10.0.1.11:8080;
}
注意：增删节点或调整顺序会改变哈希映射关系，导致大批用户 Session “漂移”。扩容建议用 consistent hash（stream 模块）或改用外部 Session 存储方案。
它适合什么场景，又不适合什么
适用于内网访问、IP 分布分散且稳定的环境，比如企业办公系统、后台管理平台。不适合：
- 大量用户走同一出口（如校园网、运营商 NAT），IP 高度集中，造成后端负载严重倾斜
- 移动端频繁切换 Wi-Fi/4G，IP 变更频繁，Session 断连率高
- 需要严格负载均衡或灰度发布，而 ip_hash 天然破坏轮询公平性
真要长期支撑业务，建议把 Session 统一存到 Redis，并配合 Spring Session 或 Tomcat Redis Session Manager 实现跨节点读写一致——ip_hash 只应作为快速验证或过渡期的兜底手段。
