ip_hash不适合提升缓存命中率，因其按客户端ip哈希分发请求，而缓存命中依赖url等请求内容一致性；不同用户访问同一url因ip不同被分至不同后端，导致重复回源、缓存无法复用，且nat/cdn下易造成单点压力与扩缩容时大规模缓存失效。
ip_hash 不能用来优化分布式系统的缓存命中率，配置它反而会降低命中率。
为什么 ip_hash 不适合提升缓存命中率
它把请求按客户端 IP 哈希分发，而缓存是否命中取决于请求内容（比如 URL）是否一致。两个不同地区用户访问同一个商品页 /item/123456，IP 不同 → 路由到不同后端 → 各自回源、各自缓存 → 缓存无法共享。
- NAT 或 CDN 场景下，成百上千用户共用一个出口 IP，全打到同一台后端，其余节点闲置，缓存利用率极低
- 增减后端节点时，ip_hash 会大规模重映射，大量请求转向新节点，导致缓存集体失效、集中回源
- 后端若按 URI 生成缓存 Key，而 Nginx 却按 IP 分发，维度完全错位，缓存形同虚设
真正有效的做法：用 request_uri 做一致性哈希
让相同 URL（含路径和查询参数）始终落到同一台后端，天然匹配后端缓存逻辑，支持平滑扩缩容。
- 配置简单：hash $request_uri consistent; 写在 upstream 块中
- 可配合 map 预处理 URI，比如过滤 utm_ 参数、标准化编码，保证哈希稳定性
- 节点增减时仅影响约 10% 请求，缓存击穿可控
- 无需额外模块（Nginx 1.19.0+ 原生支持）
什么情况下 ip_hash 看似“有用”
仅限极少数特殊场景，且不是真正提升资源级缓存复用：
- 所有用户都走固定出口 IP（如内网测试环境），且后端无状态、不依赖缓存
- 后端使用全局共享缓存（如 Redis 集群），且所有节点 Key 规则完全一致
- 每个用户只访问专属接口（如 /user/123/profile），此时 ip_hash 把“用户流”固定到一台机器，减少重复计算——但这本质是降并发压力，不是提高缓存命中率
推荐配置示例
替代 ip_hash 的标准写法：
upstream api_backend {
hash $request_uri consistent;
server 10.0.1.10:8080;
server 10.0.1.11:8080;
server 10.0.1.12:8080;
}
如需更精细控制，可先清洗 URI：
map $request_uri $clean_uri {
~^(?<path>/[^?]*)(\?.*)?$ $path;
default $request_uri;
}
upstream api_backend {
hash $clean_uri consistent;
...
}</path>
