ip_hash导致IP倾斜瓶颈，需四步排查：确认负载失衡、定位问题IP、验证哈希逻辑、分层优化缓解。
当使用 ip_hash 时，Nginx 会将同一个客户端 IP 的所有请求固定转发到同一台后端服务器。如果某个大客户（如 CDN 回源 IP、企业出口网关）流量极高，就可能让对应后端节点 CPU、连接数或带宽打满，而其他节点空闲——这就是典型的“IP 倾斜瓶颈”。排查需从确认现象、定位源头、验证哈希行为、评估影响四步入手。
确认是否真由 ip_hash 引发不均
先看 Nginx 访问日志中各 upstream 节点的请求分布是否严重失衡：
- 用
awk '{print $9}' access.log | sort | uniq -c | sort -nr统计后端响应状态码和上游地址（若日志含$upstream_addr） - 对比各节点的请求数、5xx 比例、平均响应时间，确认是否某台长期高负载
- 临时关闭
ip_hash（改用least_conn或轮询），观察负载是否立刻均衡——这是最直接的反证
识别并分析“问题 IP”本身
不是所有大客户都该被归为异常，要区分是真实业务 IP 还是聚合出口：
- 查日志中访问量 Top 10 的客户端 IP，重点关注：CDN 回源地址（如 Cloudflare、阿里云全站加速）、运营商 NAT 网关、企业防火墙出口 IP
- 用
whois或 IP 归属库判断是否属于 /24 或更大网段的共享出口（例如某省移动出口 IP 可能服务数十万用户） - 检查该 IP 的 User-Agent、Referer、请求路径特征——是否集中访问静态资源？是否触发了高频回源？
验证 ip_hash 的哈希逻辑与实际映射
Nginx 的 ip_hash 是对 IPv4 地址前 3 段做哈希（如 192.168.1.x → 192.168.1），IPv6 则取前 64 位。这意味着：
- 同一 C 段内所有 IP 都会落到同一后端（例如
10.0.1.100和10.0.1.200必然同节点） - 可通过
nginx -t && nginx -s reload后抓包或用小脚本模拟哈希：Python 中用hashlib.md5(b'10.0.1.100').hexdigest()[-1]类比（注意 Nginx 实际算法是内部哈希，但分布趋势可参考） - 在测试环境用不同 IP 请求，配合
$upstream_addr日志字段，验证哈希是否符合预期
针对性缓解而非简单禁用
直接去掉 ip_hash 可能破坏有状态业务（如 PHP Session 依赖源 IP 粘性）。更稳妥的做法是分层优化：
- 对已知 CDN 或大型出口 IP，用
geo指令将其划入独立 upstream（不启用 ip_hash），再用least_conn分流 - 升级到 Nginx Plus 或开源版 1.19+，使用
hash $remote_addr consistent;替代ip_hash，支持一致性哈希，增减后端时仅少量键重映射 - 在 upstream 中为高负载节点临时加权（
weight=2）或限速（limit_rate），争取扩容窗口期
本质是把“IP 级别粘性”升级为“业务场景级策略”——大客户走动态调度，普通用户保会话稳定。不复杂但容易忽略。
