ip hash 是 nginx 的会话保持机制，非 session 共享方案，通过客户端 ip 哈希固定路由至同一后端服务器，依赖 ip 与 upstream 列表稳定；支持 ipv4/ipv6，不兼容 weight、cdn 代理及 nat 环境，仅适用于 ip 离散且稳定的短期过渡场景。
IP Hash 是 Nginx 提供的一种负载均衡策略，它本身不“共享” Session，而是通过**会话保持（Session Persistence）**的方式绕过 Session 共享问题：让同一客户端的请求始终落到同一台后端服务器上，从而复用该服务器本地已有的 Session 数据。
IP Hash 的工作原理
它对客户端 IP 地址做哈希运算，再对后端服务器数量取模，结果决定请求分发到哪台服务器。只要 IP 不变、后端服务器列表不变，哈希结果就固定。
- 支持 IPv4 和 IPv6（v1.7.2+）
- 哈希过程是确定性的，不依赖请求路径、Header 或 Cookie
- 即使配置了 weight，IP Hash 仍优先保证同一 IP 固定路由，weight 仅在新增/下线节点时影响哈希空间分布
为什么能缓解 Session 共享问题
在无状态设计缺失或改造成本高的老系统中，Session 默认存于单机 JVM 内存（如 Tomcat 的 ConcurrentHashMap）。若负载均衡随机分发请求，用户登录后跳转可能落到无 Session 的机器，触发重复登录。
- 启用
ip_hash后，用户 A（IP 为 192.168.1.100）每次请求都命中 server1，其 Session 始终有效 - 无需修改应用代码，不依赖 Redis 或数据库，零侵入
- 适合内网环境、固定办公网络、或用户 IP 高度离散的公网场景
使用时的关键注意事项
IP Hash 看似简单，但实际部署中容易踩坑：
-
不能直接删除宕机节点：必须用
down标记（如server 127.0.0.1:8081 down;），否则哈希空间重算，大量用户会话“漂移”失效 - 局域网用户易失衡：NAT 网关后所有用户 IP 相同（如 10.0.0.1），全部压到一台后端，造成热点
- 不兼容代理链路：CDN、公司正向代理、运营商 NAT 会使真实客户端 IP 丢失，Nginx 拿到的是代理 IP，导致大量用户被路由到同一台服务器
- IPv6 地址变动敏感：部分移动网络 IPv6 前缀会周期性变化，导致哈希值改变、会话中断
替代或补充方案建议
当 IP Hash 不适用时，可结合业务实际情况选择：
- 前端透传真实 IP：在 CDN 或 LB 层设置
X-Real-IP或X-Forwarded-For，Nginx 配置set_real_ip_from+real_ip_header，再基于真实 IP 做 hash - 改用 cookie 亲和（
sticky模块或商业版sticky_cookie_insert）：按浏览器 Cookie 绑定后端，规避 IP 共享问题 - 彻底解耦 Session 存储：接入 Redis / Memcached，配合 Spring Session 或 PHP 的
session.save_handler=redis，实现真正共享
