ip hash 仅实现会话保持而非同步，依赖客户端ip哈希绑定后端；真正跨节点session同步需redis等共享存储，二者可协同优化：ip_hash降低redis压力，redis提供故障兜底。
IP Hash 策略本身不提供 Session 同步能力，它只是把同一客户端 IP 的请求“钉”在固定后端节点上，让 Session 数据自然留在本地内存里——这叫会话保持（Sticky Session），不是同步。
ip_hash 只负责路由固定，不负责数据共享
它通过哈希客户端 IPv4 前三段（如 192.168.1.x 视为相同）或完整 IPv6 地址，再对当前可用后端数量取模，决定转发目标。只要 IP 不变、后端列表顺序和数量不变，用户就始终落到同一台机器。
- 不依赖 Redis 或数据库，零代码改动，适合老系统快速上线
- 无法应对节点宕机：一旦绑定的服务器挂掉，本地 Session 消失，用户会重新登录
- 不解决 NAT/代理问题：公司出口、CDN、WAF 下大量用户共用一个公网 IP，全被压到单台后端
- 扩容缩容或调整 server 顺序时，哈希映射整体偏移，大量用户 Session “漂移”
真正实现跨节点 Session 同步，必须靠外部存储
要让任意后端都能读写同一份会话状态，得把 Session 数据从 JVM 内存抽离出来，统一存到共享存储中。Redis 是最常用方案：
- Spring Boot 项目引入
spring-session-data-redis，加@EnableRedisHttpSession注解即可 - 配置
spring.session.store-type=redis和连接参数，Session ID 仍走 Cookie（如 JSESSIONID），但底层读写全走 Redis - 即使某台服务宕机，新请求被分发到其他节点，也能从 Redis 中还原完整会话，用户无感知
- Redis 建议用 Sentinel 或 Cluster 部署，避免单点故障导致全站会话中断
ip_hash 与 Redis 配合使用更合理
两者不是替代关系，而是协同优化：
- ip_hash 降低 Redis 的读写压力：多数请求落在原节点，Session 读写走本地内存，只在创建、更新、过期时才访问 Redis
- Redis 提供兜底能力：当节点故障或用户 IP 变化（如移动网络切换基站），会话仍可延续
- 注意 Session Filter 必须全局生效，所有请求都要经过
SessionRepositoryFilter，不能部分走本地、部分走 Redis - 生产环境建议逐步弱化 ip_hash 依赖，改用轮询 + Redis，更利于弹性扩缩容和负载均衡
比 ip_hash 更可靠的会话路由替代方案
如果业务已暴露 NAT、代理、频繁扩缩容等问题，建议升级路由策略：
- 用 Cookie 哈希代替 IP 哈希：
hash $cookie_JSESSIONID consistent;，抗代理干扰更强 - TCP/UDP 四层转发场景（如数据库代理）必须用
stream模块配合hash $remote_addr consistent; - 前端透传可信用户标识（如 token 或 user_id），用
hash $arg_token实现更精准的亲和性
