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 启动会报错。该策略本身不支持权重分配。

Skill Weave Chains — 技能链路由引擎

开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。

下载

哪些情况会让会话“断连”

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 分配稳定性与故障转移行为。