IP Hash策略无法优化异构客户端流量，仅保证同一IP固定路由，易因NAT、IP切换、CDN回源等导致单点过载或会话中断；应结合real_ip模块、业务分流、cookie hash或无状态设计替代。
IP Hash 策略本身不优化异构客户端流量，它只保证同一客户端 IP 始终路由到同一后端节点。所谓“异构客户端流量”（如移动用户、企业内网用户、CDN 回源、爬虫等）的分布差异，恰恰是 IP Hash 的主要短板——它无法识别客户端真实能力或业务优先级，反而可能放大不均衡。
IP Hash 的本质是会话绑定，不是流量调度
它的核心逻辑是：对客户端 IP 做哈希（IPv4 取前 3 段，IPv6 全地址），再模运算映射到 upstream 中的固定索引。只要 upstream 列表不变，结果就确定。这意味着：
- 同一个办公室用户通过 NAT 上网，所有请求都落到同一台后端，极易造成单点过载
- 手机用户切换 Wi-Fi/4G/5G，IP 变更后会话中断，本地缓存或 WebSocket 连接丢失
- CDN 回源流量集中于少数出口 IP，导致后端某几台机器 CPU 长期超 90%
真正在意异构流量时，该用什么替代或补充？
单纯依赖 ip_hash 无法应对客户端多样性。更合理的做法是分层处理：
- 前端透传真实标识：配合 real_ip 模块和 X-Forwarded-For 头，把 CDN 或 LB 后的真实用户 IP 提取出来再哈希
- 按业务类型分流：用 map 指令识别 User-Agent、Referer 或请求路径，将管理后台、API、静态资源等路由到不同 upstream，再各自启用适合的策略
- 混合策略兜底：对登录态用户用 cookie hash（hash $cookie_sessionid），对未登录访客用 ip_hash，对爬虫单独限流并指向低优先级集群
如果必须用 ip_hash，怎么减轻倾斜风险？
不能避免问题，但可以降低影响程度：
- 在 upstream 中预留冗余节点（比如 4 台变 6 台），稀释单个哈希桶的负载压力
- 配合 max_fails=1 fail_timeout=15s，快速隔离异常节点，避免故障放大
- 定期采集各节点的 active connections 和 request rate，用 Prometheus+Alertmanager 设置倾斜告警（例如某节点连接数超均值 2.5 倍）
什么时候该果断放弃 ip_hash？
以下情况建议直接换策略：
- 后端服务已支持分布式 Session（如 Redis 共享）或无状态设计
- 业务大量依赖移动端，且用户网络频繁切换
- 使用了四层 SLB 或云厂商 ALB，X-Forwarded-For 不可靠或被篡改
- 需要灰度发布、AB 测试或按地域路由，而 ip_hash 无法满足粒度要求
