直接用 hash $request_uri consistent 是提升静态资源缓存命中率最直接有效的方式，确保相同 URL（含路径和查询参数）始终路由至同一后端，避免重复回源与缓存碎片；$request_uri 因含完整路径及原始查询字符串、区分大小写且不自动解码，能精确标识资源逻辑版本，优于 $uri、$args 和 $remote_addr；配置须满足：必须带 consistent 参数、禁用 weight 等干扰指令、规范 URI 编码，并配合后端缓存 Key 归一化及 proxy_cache_lock 等措施。
直接用 hash $request_uri consistent 是提升静态资源缓存命中率最直接有效的方式。它让相同 URL（含路径和查询参数）始终打到同一台后端，避免多台机器各自缓存同一资源，大幅减少重复回源和缓存碎片。
为什么 $request_uri 是最佳哈希键
$request_uri 包含完整路径与原始查询字符串（如 /static/logo.png?v=2.4.1），区分大小写、不自动解码，能精确标识一个静态资源的逻辑版本。相比其他变量：
-
$uri 丢弃查询参数，
/a.js和/a.js?v=2被视为不同资源，缓存无法复用； -
$args 只有参数，缺少路径信息，无法区分
/img/1.jpg和/css/app.css； - $remote_addr 在 NAT、CDN 或多设备场景下极易打散，且与资源本身无关，无法保证资源级缓存亲和。
基础 upstream 配置要点
必须满足三项硬性条件，否则一致性效果失效或配置报错：
- 指令必须写作
hash $request_uri consistent;，consistent参数不可省略； - 所有
server行不能带weight=、backup或max_fails，这些参数在原生 hash 模式下被忽略甚至导致启动失败； - 确保客户端请求 URI 编码规范，避免未编码空格、中文或乱序参数（如
?a=1&b=2与?b=2&a=1哈希结果不同）；必要时用map指令预处理归一化。
配合后端真正生效的关键动作
仅靠 Nginx 路由不够，后端缓存行为必须对齐：
- 各节点生成的缓存 Key 规则要一致，例如统一 strip 掉
utm_*、_t=等无关追踪参数； - 推荐使用共享缓存（如 Redis 集群）替代纯本地内存缓存，避免单机容量瓶颈和冷启动抖动；
- Nginx 层开启
proxy_cache_lock on;，防止缓存未命中时多个相同请求并发回源； - 监控
$upstream_cache_status日志字段，确认 HIT 比例真实上升，而非仅路由“看起来更稳定”。
常见问题与规避建议
实际部署中容易踩坑，需针对性处理：
- 若 URL 中含高频变动参数（如
&ts=1712345678），应改用$uri，或通过map构造净化后的变量再哈希； - 某资源访问极不均衡（如首页 banner 图被千万次请求），单台机器可能成为热点，可结合
least_conn二级调度或前置 CDN 分流； - 后端节点性能差异大时，原生 hash 无法调节负载，此时建议引入 LVS 或专用 LB 做前置分层，Nginx 专注 URI 级缓存亲和。
