ip_hash是Nginx基于客户端IP哈希实现会话保持的轻量级机制，通过哈希IPv4前3段或IPv6地址并对可用后端数量取模，确保同一IP请求始终路由至固定服务器，缓解Session丢失问题，但不支持weight等参数，仅适用于HTTP upstream。
ip_hash 和分布式缓存共享会话是两种不同思路的方案，不能“结合使用”——它们解决的是同一问题（Session 一致性）但逻辑互斥：ip_hash 是绕过共享、靠绑定实现会话保持；而 Redis/Memcached 等分布式缓存是真正实现 Session 共享。选其一即可，混用反而引入风险。
ip_hash 的定位很明确：不共享，只绑定
它让同一个客户端 IP 的请求始终打到同一台后端服务器上，使 Session 自然留在那台机器的内存里（比如 Tomcat 的 HttpSession），避免反复登录。它不依赖外部存储，也不要求后端应用改造，但前提是：
- 客户端真实 IP 稳定（如内网环境）
- upstream 列表不变（增删节点或调整顺序会导致大批用户 Session 漂移）
- 没有多层代理干扰，或已用 real_ip_module 正确还原原始 IP
- IPv4 地址只取前三段哈希（192.168.1.x 全视为相同 IP），NAT 环境下易导致单台过载
真要共享 Session，就该用分布式缓存方案
如果业务需要弹性扩缩容、高可用切换、或多地域部署，ip_hash 就不再适用。此时应放弃“绑定”，转向“共享”：
- 后端应用接入 Spring Session（Java）、express-session + redis（Node.js）等标准会话中间件
- 所有服务器读写统一的 Redis 实例（或集群），Session 数据不再绑定某台机器
- Nginx 回归无状态角色，可自由使用轮询、least_conn 等算法，负载更均衡
- 无需配置 ip_hash，也不用操心 real_ip_module 或 upstream 变动影响
为什么不要把两者混在一起
有人想“既用 ip_hash 防漂移，又用 Redis 做兜底”，这会带来实际问题：
- ip_hash 已强制路由，Redis 写入变成冗余操作，增加延迟和资源消耗
- 若某台后端宕机，ip_hash 会将原属它的流量重分配，但新机器从 Redis 读取 Session 时可能遇到过期、并发修改等问题
- 开发和运维需同时维护两套 Session 逻辑，出问题时难以定位是绑定失效还是缓存异常
- ip_hash 不支持 weight、backup 等参数，限制了运维灵活性；而分布式缓存天然支持故障转移与自动分片
选型建议看场景
快速判断该用哪个：
- 小规模内网系统、IP 固定、短期上线、无共享存储能力 → ip_hash 可行，配置简单
- 公有云/混合云部署、有 CDN/WAF、用户 IP 经常变化、需水平扩容或灰度发布 → 必须用 Redis + Spring Session 类方案
- 已有 Session 共享机制但偶发登录中断 → 优先排查 Redis 连接、序列化、超时配置，而不是加 ip_hash 补丁
