ip_hash是Nginx基于客户端IP哈希实现会话保持的轻量级机制，通过哈希客户端IPv4（前3段）或IPv6地址并对可用后端数量取模，确保同一IP请求始终路由至固定服务器，从而缓解Session丢失问题，但依赖IP与服务器列表稳定性，不支持weight等参数，仅适用于HTTP upstream。
ip_hash 是 Nginx 提供的一种轻量级会话保持机制，它不依赖外部存储，靠客户端 IP 哈希值把请求“钉”在某台后端服务器上，能快速缓解分布式登录中因 Session 不共享导致的反复跳登录页问题。但它不是 Session 共享方案，而是对架构短板的临时兜底。
ip_hash 怎么起作用？关键在 IP 和服务器列表的稳定性
它对客户端 IPv4 地址（取前 3 段）或 IPv6 地址做哈希，再对当前 upstream 中可用 server 的数量取模，结果固定指向其中一台。所以只要两个条件不变——用户真实 IP 不变、upstream 里 server 的顺序和数量不变——请求就始终落到同一台机器，Session 自然可命中。
- 默认用 $remote_addr 做哈希源；若前端有 CDN、WAF 或多层代理，必须配置 real_ip_module，用 set_real_ip_from + real_ip_header 把原始 IP 还原出来，否则哈希的是代理节点 IP，完全失效
- 不支持 weight、backup、down 等参数；加了 weight 会导致 Nginx 启动失败
- 仅适用于 HTTP upstream，stream 模块需改用 hash $remote_addr consistent;
典型配置写法与避坑点
配置本身很简单，但几处细节错不得：
- ip_hash 必须紧贴 upstream 块首行，不能缩进，也不能和其他 hash 指令（如 hash $cookie_jsessionid）共存
- proxy_set_header 要传 X-Real-IP 和 X-Forwarded-For，方便后端日志和风控识别真实来源
- 示例配置中 server 行只写 IP:PORT，不带协议或路径；多台机器顺序调整会改变哈希映射，扩容缩容务必谨慎
ip_hash;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
}
为什么它常被选作“过渡方案”？适用场景很具体
它见效快、零业务改造，适合这些情况：
- 遗留系统尚未接入 Redis 或 Spring Session，又急需上线灰度流量
- 内网办公环境，员工 IP 固定且无 NAT 冲突，比如企业 OA 或内部管理系统
- 测试环境快速验证负载逻辑，避免频繁登录干扰调试
但公网用户场景要格外小心：手机切 WiFi/4G、家庭宽带动态拨号、校园网/NAT 共享出口，都会让 IP 变动，导致会话中断。
真正该走向哪里？别把 ip_hash 当终点
长期卡在 ip_hash 上，等于把扩展性、高可用和用户体验都押在 IP 稳定性上。更可持续的方向是解耦 Session 与具体机器：
- 统一 Session 存储：用 Redis 托管 JSESSIONID 或 PHPSESSID，配合 Spring Session 或 Tomcat RedisSessionManager
- 全面 Token 化：前端存 JWT，后端校验签名+有效期，彻底无状态，天然支持任意扩缩容
- 增强型粘性方案：用 hash $cookie_jsessionid 比 ip_hash 更精准，前提是 Cookie 安全可靠且服务端能生成加密 session cookie
- 配套健康检查：在 upstream 中加上 max_fails=3 fail_timeout=30s，避免故障机持续接收 ip_hash 流量
