ip_hash通过哈希客户端ipv4前3字节或ipv6前64位实现固定路由，需置于upstream首行、禁用weight等参数；nat和ipv6子网易致负载倾斜，建议改用cookie或consistent hash替代。

直接在 upstream 块里加 ip_hash; 指令，就能实现基于客户端 IP 的固定路由分发。它不依赖 cookie 或 session，靠的是对客户端 IPv4 地址（或 IPv6 前 64 位）做哈希运算，确保同一 IP 的请求始终落到同一台后端服务器上，适合需要会话保持的场景，比如登录态、购物车等。

基础配置写法

只需在 upstream 定义中加入 ip_hash，其他 server 行照常写：

• upstream backend {
• ip_hash;
• server 192.168.1.101;
• server 192.168.1.102;
• server 192.168.1.103;
• }

注意：ip_hash 必须放在所有 server 行之前，且不能和 weight、backup、max_fails 等参数混用——这些参数在启用 ip_hash 后会被忽略。

Skill Weave Chains — 技能链路由引擎

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

下载

IPv6 场景要注意什么

Nginx 默认只取 IPv6 地址的前 64 位做哈希，这意味着同一 /64 子网下的多个客户端可能被映射到同一个后端节点，造成负载倾斜。

• 如果后端服务部署在云环境或使用 SLB，且客户端多为 IPv6，建议搭配真实 IP 透传（如 X-Forwarded-For）+ 自定义变量 + hash $http_x_forwarded_for consistent; 替代原生 ip_hash
• 或者升级到 Nginx 1.19+ 并启用 hash $remote_addr consistent;（需手动指定哈希方式，不走 ip_hash 指令）

NAT 环境下的实际影响

当用户经过公司防火墙、运营商 NAT 或家用路由器时，大量不同用户会共享同一个出口 IP，全部被分配到同一台后端服务器，容易导致单点过载。

• 这不是配置错误，而是 ip_hash 的固有局限
• 若业务允许，可改用 hash $cookie_session_id; 或 hash $arg_token; 等更细粒度的会话标识
• 必须用 IP 维持会话时，建议配合健康检查与动态剔除机制，避免某台后端因流量突增而雪崩

验证是否生效

修改配置后重载 Nginx（nginx -s reload），然后用多个不同公网 IP 访问，并查看 Nginx access log 中每条请求的 $upstream_addr 字段：

• 同一 IP 的多次请求，$upstream_addr 应始终显示相同后端地址
• 不同 IP 的请求，大概率落在不同后端（但哈希碰撞仍可能发生）
• 若发现某 IP 请求频繁切换后端，检查是否启用了代理、CDN 或误配了 real_ip_header