ip_hash是临时粘性补救措施，非无状态改造方案；适用于内网IP固定、内存Session未迁移场景，需配套real_ip配置与多节点部署，避免单点压垮、扩容漂移、故障不重平衡等问题，最终应分阶段演进至Redis Session、JWT Token及封装适配的无状态架构。

ip_hash 不是无状态改造的方案，而是有状态应用在未完成无状态化前的临时粘性补救措施。它不能让应用变无状态，只是把用户“钉”在某台有状态的服务器上，掩盖了状态耦合问题。真正解决传统企业 Web 应用的无状态改造，应分阶段推进：先用 ip_hash 稳住线上，再逐步解耦 Session，最终落地无状态架构。

明确 ip_hash 的定位与适用边界
ip_hash 是 Nginx 原生的轻量级会话保持机制，仅适用于以下真实场景：

• 后端仍使用内存 Session（如 Tomcat 默认配置、PHP file session）且暂无法接入 Redis
• 内网办公环境 IP 相对固定（如 192.168.10.x/24），NAT 规模可控
• 系统处于灰度迁移期，需零代码改动快速止血登录态丢失问题
• WebSocket 长连接类服务（如在线审批、内网消息推送），必须保证单连接路由固化

它不适用于：公网移动端、4G/5G 用户、大型校园网、多层 CDN/WAF 架构——这些场景下客户端 IP 极易复用或漂移，ip_hash 反而引发热点和雪崩。

基础配置必须闭环，缺一不可
仅写 ip_hash; 远不够，必须同步落实三项配套：

• 在 upstream 块首行启用，后端至少定义两台真实服务节点（不能只写 localhost 或单地址）
• 在 http 块中配置可信代理段与头字段还原：

  set_real_ip_from 10.0.0.0/8;
  set_real_ip_from 192.168.0.0/16;
  real_ip_header X-Forwarded-For;

• 在 location 中透传真实 IP：

  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

若跳过任一环，$remote_addr 就是上一跳代理 IP，所有请求哈希结果一致，流量全打到同一台后端。

避开企业环境中高频失效点
传统企业网络常踩以下坑：

• 内网使用 192.168.1.x 段时，ip_hash 仅取前三段（即 192.168.1），整个 C 类子网用户被哈希为“同一个 IP”，必然压垮单节点
• 运维扩容一台新服务器并加入 upstream，节点总数变化 → 全量哈希映射重排 → 大批用户 Session “漂移”失效
• 某台后端被 down 或健康检查失败，ip_hash 不自动重平衡；原 IP 段请求仍尝试发往故障节点，直到超时才 fallback，用户体验断连

此时不应硬扛，而应记录日志确认 $remote_addr 和 upstream_addr 关系，验证是否真由 IP 导致不均。

向无状态演进的可行路径
ip_hash 只是脚手架，真正的无状态改造建议按序推进：

• 第一阶段：接入 Redis 存储 Session（Spring Boot 配 spring.session.store-type=redis；PHP 改 session.save_handler = redis），停用 ip_hash，改用 least_conn 或轮询，验证跨节点登录态一致性
• 第二阶段：将敏感操作（如审批提交、电子签章）所需的状态上下文，改由前端携带加密 Token（如 JWT），后端纯校验不查 Session
• 第三阶段：对遗留模块做适配封装，例如用 Spring Session 的 @EnableRedisHttpSession(maxInactiveIntervalInSeconds = 1800) 统一管控过期，避免业务代码侵入

整个过程无需一次性重写，可按业务线灰度切流验证。

不复杂但容易忽略