ip_hash无法兼顾算力平衡，因其设计目标是确定性而非均衡性：不支持weight、nat下易负载倾斜、节点变更导致全量映射重排；推荐改用hash $remote_addr consistent替代，支持权重与平滑扩缩容。
ip_hash 能实现客户端 IP 到后端节点的固定映射，但“兼顾多节点算力平衡”和“ip_hash 本身”存在天然矛盾——它不感知后端负载、不支持权重、节点变动时哈希整体偏移。所以真正可行的路径不是“在 ip_hash 上加平衡”，而是用更合适的哈希策略替代它，同时保留会话粘滞效果。
为什么 ip_hash 无法兼顾算力平衡
ip_hash 的设计目标是确定性，不是均衡性：
- IPv4 只取前三段哈希（如 192.168.1.100 和 192.168.1.200 映射到同一台），内网 NAT 下极易造成单节点过载
- 不支持 weight、backup 等参数，所有后端默认等权重，无法按 CPU/内存差异调整承接比例
- 某台 server 标记为 down 时，Nginx 剔除该节点，剩余节点重新分配请求，但原有 IP 映射关系仍在剩余节点上维持——这会导致部分节点瞬间流量翻倍
- 节点扩容或缩容时，全部哈希映射重排，大量用户会话漂移
推荐方案：用 hash + consistent 替代 ip_hash
这是官方支持、无需第三方模块、兼容主流 Nginx 版本（1.7.2+）的成熟做法，既保持 IP 粘性，又支持加权与稳定性：
- 用 hash $remote_addr consistent; 替代 ip_hash；它对客户端真实 IP 做一致性哈希，同一 IP 长期落在同一后端
- 每个 server 可设 weight（如 weight=3），权重决定其在哈希环上的虚拟节点数量，自然实现算力倾斜分配
- 新增或下线节点时，仅影响邻近少量请求，会话漂移远小于 ip_hash
- 配置示例：
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;
}
必须同步做好的三件事
否则 hash 效果大打折扣，甚至失效：
-
确保 $remote_addr 是真实客户端 IP：若前端有 CDN、WAF 或代理，需在 http 块中启用 real_ip_module：
set_real_ip_from 192.168.0.0/16;
set_real_ip_from 10.0.0.0/8;
real_ip_header X-Forwarded-For; -
location 中透传真实标识：
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; - 避免节点数过少：一致性哈希在 ≥3 台后端时效果更稳；若只有 2 台，建议增加一台低配 standby 节点或改用业务标识哈希（如 $cookie_sessionid）
更优选：按业务标识哈希（推荐用于登录态场景）
如果粘滞目标是“用户登录不掉线”，而非“IP 不换机器”，那基于应用层标识的哈希更精准、更抗 NAT 和代理干扰：
- 用 hash $cookie_jsessionid consistent; 或 hash $cookie_sessionid consistent;
- 服务端生成 session ID 逻辑稳定即可，天然兼容 weight，且不受出口 IP 变化影响
- 可设置 fallback：先按 cookie 哈希，缺失时再 fallback 到 IP：
hash $cookie_sessionid consistent;
hash $remote_addr consistent;
