Nginx原生ip_hash不支持权重，混用weight会导致启动失败；必须改用hash $remote_addr consistent配合weight实现带权持久化会话绑定，并确保真实IP透传与健康检查。
直接说结论：Nginx 原生 ip_hash 不支持权重，一旦启用就自动禁用 weight，配置中混用会启动失败。所谓“带权重的持久化会话绑定”，不能靠 ip_hash 实现，必须换用更灵活的 hash 指令配合一致性哈希（consistent）和自定义变量。
为什么 ip_hash 不能加权重
这是 Nginx 的硬性限制：
-
ip_hash是独立负载策略，内部已固化哈希逻辑和轮询兜底机制 - 配置中若对 server 写
weight=2，Nginx 会报错退出：“ip_hash and weight cannot be used together” - 它对 IPv4 地址只取前三个八位组做哈希（如
192.168.1.x全视为同一 IP），也不感知后端健康状态变化
真正可行的带权持久化方案：hash + consistent
用原生 hash 指令替代 ip_hash，可自由组合变量与权重，同时保持会话粘性：
- 基础写法：
hash $remote_addr consistent;—— 效果接近ip_hash，但支持weight - 增强写法：
hash "$remote_addr:$server_port" consistent;—— 避免端口复用导致哈希冲突 - 加权示例：
upstream backend {
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;
}
此时请求按客户端 IP 哈希固定路由，同时权重影响节点在哈希环上的虚拟节点数量，实现“粘性 + 加权”的双重效果。
更稳健的业务级会话绑定方式
单纯依赖 IP 有明显短板（NAT、移动网络、IPv6 兼容性差），建议按业务实际选择更精准的键：
- 按登录态 Cookie 绑定：
hash $cookie_sessionid consistent;—— 要求客户端携带稳定 session ID - 按 JWT 用户 ID 解析绑定（需 OpenResty 或 Lua）：
hash $jwt_uid consistent; - 按请求头中的用户标识：
hash $http_x_user_id consistent;—— 适合网关层已透传用户信息的架构
配套要点不能漏
光配 hash 不够，还要保障真实可用性：
- 确保
$remote_addr是真实客户端 IP：若前端有 CDN 或代理，必须启用real_ip_module，并配置set_real_ip_from和real_ip_header X-Forwarded-For - 避免哈希倾斜：节点数过少（如仅 2 台）时，一致性哈希效果打折，建议 ≥3 台或搭配
keepalive复用连接 - 健康检查要跟上：原生 Nginx 开源版不支持
ip_hash下的自动剔除，可用max_fails/fail_timeout做基础探测，或集成nginx_upstream_check_module
