proxy_cache_min_uses 控制相同URI请求达到指定次数后才写入缓存，不拦截请求、无全局统计、不替代CDN低频过滤；需配合cache_key设计、proxy_cache_lock等避免无效回源。
当使用 Nginx 的 proxy_cache 时，proxy_cache_min_uses 并不直接“过滤 CDN 低频请求”，而是控制缓存生效的触发条件：只有某个请求被**相同 URI（及 key）连续命中达到指定次数后，才开始缓存响应内容**。它本身不拦截或拒绝请求，也不与 CDN 协同做“过滤”，但可间接减少对源站的低频回源压力。
proxy_cache_min_uses 的真实作用
该指令定义一个请求 URI（按 proxy_cache_key 计算）需被发起多少次，Nginx 才将该响应写入缓存。默认值为 1，即首次请求就缓存；设为 2 或更高，则前 N−1 次请求均不缓存、直接回源，第 N 次起才缓存并服务后续请求。
- 设为
proxy_cache_min_uses 3：同一资源前两次访问都穿透缓存，直连后端；第三次起才缓存，并用缓存响应第四次及之后的请求 - 它只影响“是否写缓存”，不影响“是否读缓存”——已缓存的资源仍会正常 serve，无论之前是否达最小次数
- 不改变请求转发行为，所有请求（包括未达阈值的）仍会发往后端，只是部分不落盘
为什么它不能替代 CDN 的低频过滤逻辑
CDN 厂商（如 Cloudflare、阿里云 DCDN）常提供“低频回源保护”功能，例如自动识别 UV 低、QPS 小的 URL，主动不缓存或强制跳过边缘节点缓存，直接回源或返回 404/503。而 Nginx 的 proxy_cache_min_uses：
- 无全局统计能力：仅基于单台 Nginx 实例的本地请求计数，无法聚合多节点流量判断“是否低频”
- 无请求特征分析：不识别 User-Agent、Referer、参数变化频率等，仅看 URI（或 cache_key）是否重复
- 不阻断请求：即使某 URL 只访问 1 次，仍会回源——它不“过滤”，只是“暂不缓存”
如何配合 CDN 更合理地降低无效回源
若你同时使用 CDN + 自建 Nginx（作为源站或中间层），可通过组合策略减少低频请求对源站冲击：
-
在 CDN 层设置合理缓存策略：对静态资源（js/css/img）开启强缓存（Cache-Control: public, max-age=31536000），对动态接口显式设
no-cache或短 TTL，让 CDN 主动不缓存低价值路径 -
Nginx 中分路径配置 min_uses：对确定高复用的资源（如首页 HTML、公共 JS 包）设
proxy_cache_min_uses 1；对带随机参数的埋点、上报接口，用map或if跳过缓存模块，避免污染 cache key -
结合 proxy_cache_bypass 和 cache key 设计：对含用户身份、时间戳等不可缓存参数的请求，在
proxy_cache_key中排除它们，或用proxy_cache_bypass $arg_nocache显式绕过
常见误用与排查建议
实际部署中容易因理解偏差导致效果不符预期：
- 误以为设成 5 就能“挡住前 4 次请求”——其实 4 次都照常回源，且可能因并发造成多次写缓存冲突
- 未配合
proxy_cache_lock：高并发下多个相同请求同时未命中缓存，会触发多次回源（cache stampede），建议开启锁机制 - 忽略 cache key 变化：若日志中发现同一 URL 缓存命中率始终为 0，检查是否 header、cookie 或参数被意外纳入 key，导致每次 key 都不同
- 未启用
proxy_cache_valid：即使满足 min_uses，若没配有效期，Nginx 默认不缓存 2xx/3xx 响应（除非显式声明）
