ip_hash实现会话保持的核心是将同一客户端IP哈希后固定映射至同一后端服务器，需在upstream块首行配置且不支持weight；失效主因包括代理覆盖真实IP、upstream节点增删或顺序变动、NAT导致IP复用。
用 ip_hash 实现会话保持，核心是让同一客户端 IP 始终打到同一台后端服务器。它不依赖 cookie 或 session 存储，而是靠 Nginx 对源 IP 做哈希计算后取模映射，适合登录态未统一、购物车存在内存、或老系统无法改造的场景。
ip_hash 的配置写法
在 http 块中定义 upstream 时，直接加 ip_hash; 指令即可：
upstream backend_pool {
ip_hash;
server 192.168.1.101:8080;
server 192.168.1.102:8080;
server 192.168.1.103:8080;
}
注意：不能在任意 server 行后加 weight，否则 Nginx 启动会报错。该策略本身不支持权重分配。
哪些情况会让会话“断连”
ip_hash 映射关系不是永久固定的，以下操作会触发全量重散列，导致大量用户请求跳转到不同后端：
- 增删任一
server行（哪怕只是临时下线一台） - 调整
server行顺序（如把第二行移到第一行） - IPv6 用户仅用前 64 位参与哈希，若业务依赖完整地址，可能产生误匹配
- 用户经过企业 NAT 或运营商共享出口，多个真实用户共用一个公网 IP，全部被压到同一后端，造成负载倾斜甚至超载
提升稳定性的实用补救措施
虽然 ip_hash 本身无自动漂移能力，但可配合其他机制缓解风险：
- 给备用节点加上
backup标识，故障时人工启用，承接部分流量 - 为每台 server 配置
max_fails=3 fail_timeout=30s，Nginx 会在连续失败后临时屏蔽该节点（注意：屏蔽期间对应 IP 请求将返回 502） - 日志中加入
$upstream_addr字段，例如：
log_format main '$remote_addr - $upstream_addr $request_time';
便于回溯验证某 IP 是否长期落在同一后端 - 测试阶段避免用本机反复刷新，改用不同公网出口或代理工具（如
curl -x http://proxy:port）模拟多客户端行为
上线前必须验证的两件事
灰度发布时重点确认：
- 固定一个公网 IP（如手机热点），连续发起 20+ 次请求，检查
$upstream_addr日志是否始终一致 - 手动停掉其中一台后端，观察该节点原分配的 IP 流量是否真的不再到达（而非错误堆积或 502 暴增）
不复杂但容易忽略。真正上线前，务必在灰度环境验证 IP 分配稳定性与故障转移行为。
