ip hash 是会话保持策略而非性能优化方案，旨在使同一客户端请求稳定路由至同一后端服务器，适用于有状态业务，但易因出口ip集中、ipv4哈希粒度粗及节点变更引发流量倾斜与会话漂移。
IP Hash 本身不是为“高频请求”设计的性能优化方案，而是为会话保持服务的路由策略。它不提升单机吞吐或并发能力，也不缓解后端压力；它的作用是让同一客户端的请求稳定落在同一台后端服务器上——这对有状态业务（如登录态、购物车）很关键，但若滥用或配置不当，反而可能加剧热点问题。
IP Hash 的适用边界要清楚
高频请求场景下，盲目启用 ip_hash 容易导致流量倾斜：
- 大量用户来自同一出口 IP（如企业内网、校园网、移动运营商 NAT 池），所有请求会被哈希到同一台后端，造成单点过载
- IPv4 哈希只取前 3 段（如 192.168.1.x → 192.168.1），进一步放大哈希碰撞概率
- 后端节点增减会重洗哈希映射，引发批量会话漂移，对有状态服务是灾难性抖动
真正应对高频请求，得靠组合策略
单纯依赖 ip_hash 无法解决高频压力，需配合其他机制：
- 前置缓存：静态资源用 Nginx 自身缓存或 CDN；动态接口按业务特征加 proxy_cache，减少穿透请求
- 限流降级：用 limit_req 控制单 IP 或全局请求数，防突发洪峰打垮后端
- 健康检查 + least_conn：当会话可丢失（如无状态 API），改用 least_conn 策略，让新请求自动流向连接更少的健康节点
- 分层路由：CDN 层做 GEO 路由，Nginx 层再按 IP 做二级粘性，避免全量流量都压在一层 ip_hash 上
必须配真实 IP 识别，否则 ip_hash 失效
如果前端有 CDN、WAF 或多级代理，$remote_addr 默认是上一跳地址，不是用户真实 IP，ip_hash 就会把所有经过同一代理的请求全打到一台机器上：
- 配置 set_real_ip_from 指定可信代理网段（如 CDN 回源段、公司内网段）
- 设置 real_ip_header 为 X-Forwarded-For 或 True-Client-IP（依实际头字段而定）
- 验证是否生效：在日志中添加 $http_x_forwarded_for 和 $realip_remote_addr 字段对比确认
替代方案比硬扛更合理
当高频 + 会话保持同时存在，ip_hash 往往不是最优解：
- 改用 session 共享：Redis 存 session，后端无状态，就能放心用轮询或 least_conn
- 改用 cookie hash：proxy_cookie_path 配合 hash $cookie_session_id，把粘性控制权交给应用层，更可控
- 改用 consistent hash（stream 模块）：适用于 TCP/UDP 长连接场景，扩容时影响更小
