Nginx原生ip_hash不支持权重且无法与weight共存；但可通过hash $remote_addr consistent配合weight实现带权会话绑定，提升扩容平滑性与稳定性。
直接说结论：Nginx 原生 ip_hash 不支持权重，也无法与 weight 共存；但可通过 hash 指令 + 一致性哈希（consistent）或 hash $remote_addr consistent 实现带权重的会话绑定，兼顾稳定性与扩容平滑性。
为什么 ip_hash 不能加权
ip_hash 是固定算法，仅对客户端 IPv4 前三段（如 192.168.1.x）做哈希，再取模映射到存活 server 列表索引。它不读取 weight 参数，也不参与权重计算——配置了 weight 也会被忽略。一旦某台 server 被标记为 down，原有哈希槽会重映射，导致部分用户会话中断，且无法按能力倾斜流量。
用 hash + consistent 实现带权会话绑定
使用通用 hash 指令配合 consistent 关键字，可基于客户端 IP 构建一致性哈希环，再结合 weight 分配虚拟节点数，从而实现“带权重的会话保持”：
- 每个 server 按 weight 值生成对应数量的虚拟节点（如 weight=3 → 3 个虚拟节点）
- 客户端 IP 哈希后落在环上，顺时针找到最近的虚拟节点，即命中对应真实 server
- 新增或下线 server 时，仅影响邻近少量 key，会话漂移远少于 ip_hash
配置示例：
upstream app_cluster {
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;
}
该方式天然支持权重，且在后端扩缩容、个别节点故障时，会话中断比例显著降低，更适合有状态业务（如登录态未统一存储的旧系统）。
关键增强点：健康检查 + 自动剔除
仅靠哈希不能保证可用性。需叠加主动健康检查，避免请求打到已失联节点：
- 启用
max_fails=3 fail_timeout=30s，连续失败 3 次则临时摘除 - 搭配
health_check interval=5 fails=2 passes=2（需 Nginx Plus 或开源版编译含 health_check 模块） - 对于无 Plus 环境，可用
proxy_next_upstream error timeout http_500触发重试+自动跳过异常节点
适用场景与注意事项
该方案适合以下情况：
- 后端未接入 Redis/DB 共享 session，又需保障登录态连续
- 集群中服务器性能差异明显（如 8C16G 与 4C8G 混部）
- 业务对会话中断敏感，但无法改造应用层做无状态化
注意避开这些坑：
- CDN 或企业 NAT 后用户共用出口 IP → 改用
hash $http_x_forwarded_for consistent（需确保上游透传真实 IP） - IPv6 用户需确认 Nginx 版本 ≥ 1.11.0，否则
$remote_addr可能截断 - 不建议在高动态 IP 场景（如移动网络频繁换地址）强依赖 IP 哈希，可考虑 cookie-based sticky（需 Plus）
