nginx upstream支持普通hash和hash consistent两种哈希,但ip_hash不支持权重;推荐使用hash $variable consistent配合weight实现可加权、高粘性的持久化绑定,且需置于upstream块内server之前。

直接说结论:Nginx 的 upstream 模块支持两种 hash 类型——普通哈希(hash)和一致性哈希(hash ... consistent),但不支持在 ip_hash 指令下加权重;真正可配置、可加权、可持久化的哈希方案,是用 hash 指令配合变量(如 $remote_addr 或 $cookie_xxx),并启用 consistent 参数。
用 hash + consistent 实现带权重的稳定绑定
这是最常用也最推荐的方式,既能保留 weight,又能保证客户端长期落在同一台后端上:
- 必须写在
upstream块内,且要放在所有server行之前 - 语法格式为:
hash $variable consistent;,其中$variable可以是任意 Nginx 内置变量或自定义变量 -
consistent是关键参数,它启用一致性哈希算法,节点增减时影响范围小,粘性更稳定 - 每个
server行可正常配置weight、max_fails、fail_timeout等参数
示例配置:
upstream app_backend {hash $remote_addr consistent;
server 10.0.1.10:8080 weight=4;
server 10.0.1.11:8080 weight=2;
server 10.0.1.12:8080 weight=1;
}
按 Cookie 或登录态做哈希更可靠
如果业务真正依赖用户会话(比如登录态、购物车),仅靠 IP 不够稳定(NAT、代理、移动网络频繁换 IP),建议优先用 Cookie 值哈希:
- 使用
$cookie_jsessionid、$cookie_session_id或自定义 cookie 名(如$cookie_user_token) - 要求后端稳定生成该 Cookie,且客户端每次请求都携带(浏览器默认行为)
- 若 Cookie 缺失,Nginx 默认 fallback 到轮询;可叠加双哈希策略增强容错
双哈希兜底写法:
upstream app_backend {hash $cookie_session_id consistent;
hash $remote_addr consistent;
server 10.0.1.10:8080 weight=3;
server 10.0.1.11:8080 weight=1;
}
注意 ip_hash 的硬限制和替代场景
ip_hash 是独立指令,不是 hash 的一种变体,它有明确设计边界:
- 不支持
weight,配置即报错:ip_hash cannot be used with weighted servers - 对 IPv4 只取前三个八位组(
192.168.1.x全视为同一 IP),不适合局域网或大运营商出口 - 节点宕机时不会自动重映射,需搭配健康检查(
max_fails/fail_timeout)才实用 - IPv6 支持从 Nginx 1.19+ 开始原生可用,旧版本(如 Windows 上常见 1.18.x)会退化为轮询
确认模块是否可用
ngx_http_upstream_hash_module 是 Nginx 官方模块,主流发行版(如 Ubuntu、CentOS、Alpine 的 nginx 包)通常已内置。验证方式:
- 运行
nginx -V 2>&1 | grep -o http_upstream_hash,有输出即表示支持 - 若编译自定义 Nginx,需确保 configure 时包含
--with-http_upstream_hash_module - 无需额外加载
load_module,它是编译期静态模块











