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)统一管控过期，避免业务代码侵入
整个过程无需一次性重写，可按业务线灰度切流验证。
不复杂但容易忽略
