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 后会被忽略。
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
