Nginx原生ip_hash不支持weight，混用会导致启动失败；应改用hash $remote_addr consistent实现带权IP粘性，或更优的hash $cookie_sessionid consistent按业务标识哈希，并配套健康检查、真实IP透传和合理节点规模。
Nginx 原生 ip_hash 不支持 weight，配置中混用会直接导致启动失败，报错如 “ip_hash and weight cannot be used together”。真正可行的带权重会话持久化，必须放弃 ip_hash，改用通用 hash 指令配合 consistent 参数，并结合真实业务标识选对哈希键。
用 hash $remote_addr consistent 实现带权 IP 粘性
这是最常用、兼容性最好的替代方案。它保留客户端 IP 绑定效果，同时允许设置 weight，且具备一致性哈希的扩容稳定性：
-
hash $remote_addr consistent;将客户端真实 IP 映射到哈希环，同一 IP 长期落在同一后端 - 每个
server的weight决定其在环上虚拟节点数量（如weight=3→ 3 个虚拟节点），实现加权分布 - 新增或下线节点时，仅影响邻近少量请求，会话漂移远少于
ip_hash - 需确保
$remote_addr是真实客户端 IP：若前端有 CDN 或代理，必须启用real_ip_module，并配置set_real_ip_from和real_ip_header X-Forwarded-For
按业务标识哈希更可靠（推荐）
单纯依赖 IP 在 NAT、移动网络、IPv6 下易失效。使用应用层标识（如登录态 Cookie）绑定，粘性更强、容错更好：
- 用稳定 session cookie：例如
hash $cookie_sessionid consistent;，要求服务端生成逻辑一致、不频繁变更值 - 若 Cookie 不存在，Nginx 默认 fallback 到轮询；可叠加兜底策略，如
hash "$cookie_sessionid:$remote_addr" consistent; - 适合已透传用户信息的网关架构：如
hash $http_x_user_id consistent;或解析 JWT 中的 UID（需 OpenResty + Lua）
配套必须启用的健壮性机制
仅配哈希无法保障生产可用性，以下三点缺一不可：
-
健康检查：开源版可用
max_fails=3 fail_timeout=30s自动临时摘除异常节点；有条件建议集成nginx_upstream_check_module做主动探测 - 真实 IP 透传：确认日志和哈希变量中的 IP 是终端用户地址，而非中间代理地址
- 节点规模合理：一致性哈希在节点数 ≥3 时效果更稳；2 节点集群易出现哈希倾斜，建议补足或评估无状态改造可行性
避坑提醒
几个高频出错点务必注意：
- 不要写
ip_hash同时加weight——Nginx 启动直接拒绝 - 避免用
hash $request_uri做会话绑定——它面向缓存优化，不解决用户态粘性 - 公网部署慎用纯
$remote_addr：企业出口、4G/5G 共享 IP 场景下会大量会话冲突，优先切到 Cookie 或 Header 维度 - 确认 Nginx 已编译
ngx_http_upstream_hash_module（主流发行版默认包含，但精简镜像可能剔除）
