ip_hash能实现客户端IP绑定，但稳定依赖真实IP还原、后端列表固定及避开NAT/代理；必须顶格置于upstream首行、至少两台后端、禁用weight等参数，并配合set_real_ip_from和real_ip_header配置，否则会话必然漂移。
ip_hash 能让同一客户端 IP 始终打到同一台后端，但“能用”不等于“稳定”。真正实现稳定绑定，关键不在加不加那行 ip_hash;，而在真实 IP 是否准确、后端列表是否可控、NAT 和代理是否被妥善处理。
必须严格遵守的基础写法
很多配置看似正确，启动却失败或无效，往往卡在细节上：
- ip_hash 必须放在 upstream 块第一行，顶格写，不能缩进，也不能跟在注释或空行后面
- upstream 至少要定义两台后端（不能只写 localhost 或单个 server），否则 Nginx 会忽略 ip_hash
- server 行只写
IP:PORT，比如10.0.1.10:8080，不能带http://、路径或协议头 - 不能和
weight、backup、down等参数共存——加了任意一个，Nginx 启动直接报错
真实客户端 IP 是前提，不是可选项
如果前端有 CDN、WAF、Nginx 代理或多层 LB，$remote_addr 默认是上一跳地址，所有请求哈希结果相同，全打到同一台后端。必须还原真实 IP：
- 在 http 块中声明可信代理段：
set_real_ip_from 192.168.0.0/16;、set_real_ip_from 10.0.0.0/8;（按实际代理网段调整） - 指定真实 IP 来源头：
real_ip_header X-Forwarded-For; - 在 proxy_pass 的 location 中透传：
proxy_set_header X-Real-IP $remote_addr;和proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
避开导致“漂移”的三大硬伤
ip_hash 映射关系脆弱，以下操作会批量破坏绑定：
- IPv4 只取前三段哈希：192.168.1.100 和 192.168.1.254 被视为同一 IP，在 NAT 环境下极易造成单节点过载
- 后端列表变动即全量重散列：增删节点、调整顺序、临时标记某台为 down，都会让原有 IP 映射整体偏移
-
不支持四层转发：stream 模块中 ip_hash 无效，TCP/UDP 场景必须改用
hash $remote_addr consistent;
更稳的替代方案建议
当业务增长、出现 NAT 用户增多、频繁扩缩容或对 Session 稳定性要求提高时，应逐步迁出 ip_hash：
- 改用 Cookie 哈希：
hash $cookie_JSESSIONID consistent;，天然规避代理和 NAT 干扰 - 后端统一接入 Redis 存储 Session，例如 Spring Boot 配置
spring.session.store-type=redis，彻底解耦路由与状态 - 对对象存储（如 MinIO）、文件上传等强一致性场景，可继续用 ip_hash，因其分片逻辑本身依赖固定节点
