proxy_cache_min_uses 不拦截请求，仅控制第几次响应才写入磁盘缓存；设为5会导致中频请求（日访问3–4次）始终不缓存、持续回源，降低命中率并加重后端压力。
proxy_cache_min_uses 本身不拦截请求，也不减少回源次数——它只控制“第几次响应才写入磁盘缓存”。想靠它“拦截无效请求”是误用，反而可能加重后端压力。
为什么设成 5 会让缓存命中率暴跌
很多人看到“过滤低频请求”就下意识把 proxy_cache_min_uses 全局设成 5，结果发现大量接口始终 MISS，后端 QPS 却没降反升。这是因为：
- 所有请求（包括前 4 次）仍会完整回源，Nginx 只是不把响应体落盘
- 每天访问 3～4 次的中频资源（如用户头像、商品详情页）永远卡在阈值外，既无缓存又持续穿透
- 缓存区里堆的全是高复用内容（如首页 HTML），而真正需要“养热”的中频路径被系统性排除
按 location 分路径设值才是有效调优
静态资源和动态接口的访问模式差异极大，必须拆开配置。典型做法：
-
.js/.css/.png路径：设为2，过滤爬虫试探、单次调试等噪声 -
/api/user/类带 ID 的接口：若业务上存在访问聚集（如某用户突然被转发），也可设为2 -
/log?ts=或含随机参数的埋点：直接用proxy_cache_bypass $arg_ts跳过缓存，别依赖min_uses - 首页 HTML、公共 JS 包：保持
1，强复用内容没必要“养热”
必须配合 proxy_cache_lock 才能避免雪崩
当 proxy_cache_min_uses 设为 2 时，前两次请求都回源——如果没加锁，多个并发请求会同时打到后端。正确姿势：
- 开启
proxy_cache_lock on，让第二个请求等待第一个回源完成 - 设置
proxy_cache_lock_timeout 5s，防止单个请求卡死阻塞太久 - 搭配
proxy_cache_use_stale updating，让后续请求能读到旧缓存而非干等
验证是否生效？盯住 X-Cache-Status 和日志
光看配置没用，得确认行为符合预期。关键操作：
- 在
location块中加：add_header X-Cache-Status $upstream_cache_status; - 观察响应头：
MISS表示未命中且本次也未写入（可能是未达min_uses）；HIT表示已缓存并返回；BYPASS表示被proxy_cache_bypass显式跳过 - 配合 Nginx error log 中的
cache lock日志，确认锁机制是否触发
最容易被忽略的一点：这个指令完全基于单机本地计数，没有跨节点聚合能力。如果你有 4 台 Nginx 实例，同一 URL 在每台机器上都要各自达到阈值才能缓存——它不是全局热度统计，只是本地“冷启动保护”。
