Nginx原生ip_hash不支持权重，启用后配置weight会导致启动失败；需改用hash $remote_addr consistent等替代方案实现带权重的会话粘滞。
直接说结论：Nginx 原生 ip_hash 不支持权重，所以“带权重的 ip_hash 持久化会话”在标准配置中无法实现。但业务上真有这种需求，可以通过替代方案达成类似效果——关键不是硬凑 ip_hash + weight，而是按目标选对哈希维度和策略。
为什么 ip_hash 不能加 weight
这是 Nginx 的硬性限制：只要 upstream 块中启用了 ip_hash，再写 weight= 就会导致 nginx 启动失败，报错类似 "ip_hash cannot be used with weighted servers"。因为 ip_hash 的设计目标是确定性映射（同一 IP → 固定后端），而权重轮询本质是概率性调度，二者逻辑冲突。
- ip_hash 对 IPv4 地址只取前三个八位组做哈希（如 192.168.1.x 全视为同一 IP）
- 它不感知后端健康状态变化，节点宕机时不会自动重哈希，需配合健康检查模块补足容错
- IPv6 支持依赖 Nginx 版本，1.19+ 才原生有效；Windows 常见的 1.18.x 会退化为轮询
用 hash $remote_addr consistent 实现可加权的 IP 绑定
这是最贴近你需求的可行路径：放弃 ip_hash，改用通用 hash 指令，对客户端 IP 做一致性哈希，并保留 weight 支持。
- 配置示例：
hash $remote_addr consistent;
server 192.168.1.10:8080 weight=3;
server 192.168.1.11:8080 weight=1;
server 192.168.1.12:8080 weight=2;
}
-
consistent参数让哈希具备“节点增减时影响最小化”的特性，比普通 hash 更稳定 - weight 仍生效，最终请求分布近似按权重比例，同时保持同一 IP 大概率落在同一台机器（非绝对固定，但长期看粘性足够强）
- 需确认你的 Nginx 已编译
ngx_http_upstream_hash_module（主流发行版通常默认包含）
更精准的会话绑定：按 Cookie 或用户标识哈希
如果业务真正需要的是“登录态不丢失”，而非单纯靠 IP，那基于应用层标识的哈希更可靠，且天然兼容权重。
- 例如用 JSESSIONID 或自定义 session cookie：
hash $cookie_jsessionid consistent;
server 192.168.1.10:8080 weight=3;
server 192.168.1.11:8080 weight=1;
server 192.168.1.12:8080 weight=2;
}
- 前提是客户端每次请求都携带该 Cookie，且服务端生成逻辑稳定（避免频繁变更值）
- 比 IP 更抗 NAT、代理干扰，适合公网用户或移动网络场景
- 若 Cookie 不存在，Nginx 会 fallback 到轮询，可加
hash $cookie_jsessionid consistent;后再配hash $remote_addr consistent;作兜底
实际部署要注意的细节
无论选哪种 hash 方式，以下几点直接影响会话稳定性：
- 前端若有 CDN 或反向代理，
$remote_addr可能是代理 IP，必须启用real_ip_module并设置set_real_ip_from正确还原真实客户端 IP - 后端服务重启或扩容缩容时，一致性哈希能减少重分布冲击，但首次上线建议灰度验证路由收敛情况
- 不要在 server 块里重复写
proxy_set_header X-Real-IP $remote_addr，否则可能覆盖 real_ip 模块提取的结果 - 测试阶段避免用 localhost 或 127.0.0.1，它们哈希值固定，容易误判粘性是否生效
