proxy_cache_min_uses 是缓存热度门槛而非过滤器，设为3时前两次请求仍回源且不写缓存，第三次起才缓存并服务后续请求；它仅控制“何时写入缓存”，不阻断请求、不跳过回源、不影响读缓存。
proxy_cache_min_uses 不是过滤器，而是缓存“热度门槛”。它不拒绝请求、不跳过回源、也不删除已缓存项，只决定“第几次访问才把响应写进磁盘”。设为 3，意味着同一资源前两次请求仍会打到后端，且不落缓存；第三次起才开始缓存，并服务后续命中请求。
为什么需要设置大于 1 的值
默认值 1 会让所有可缓存响应立即入库，包括大量只被访问 1–2 次的低频资源（如冷门文章、临时活动页、带随机参数的调试接口）。这些内容长期占着缓存空间，却极少被复用，拉低整体缓存命中率。
- 避免缓存“一次性内容”，尤其在 CDN + Nginx 双层缓存架构中，Nginx 作为源站前置层，更需聚焦高频路径
- 减少磁盘 I/O 和内存 key 区占用，提升缓存区健康度
- 配合
inactive参数，让真正活跃的内容自然留存，冷数据更快被淘汰
如何合理设定数值
没有通用最优值，需结合业务访问特征和缓存容量评估。常见实践如下：
WebChat Voice Proxy
下载
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
- 静态资源（JS/CSS/图片）：通常保持
proxy_cache_min_uses 1，因它们天然具备高复用性 - 列表页或频道页（如
/news/list?page=1）：设为2或3，过滤掉爬虫试探、误点或单次浏览流量 - 详情页（如
/article/12345）：可设为2，兼顾新发布内容冷启动与长尾淘汰 - 含用户态参数的路径（如
/user/profile?uid=xxx）：应优先用proxy_no_cache或精简proxy_cache_key，而非依赖 min_uses
必须搭配的关键配置
单独调高 proxy_cache_min_uses 效果有限，容易引发缓存击穿或状态混乱：
-
启用
proxy_cache_lock on：防止多个相同未缓存请求同时回源，避免后端压力突增 -
精简
proxy_cache_key：剔除影响热度判断的干扰字段（如时间戳、跟踪 ID），确保相同语义请求归为一类 -
配合
proxy_cache_bypass和proxy_no_cache：对登录态、表单提交、调试参数等明确不可缓存的请求，直接绕过判断逻辑 -
监控
$upstream_cache_status：通过X-Cache-Status响应头观察MISS（未达阈值）、HIT、EXPIRED分布，验证策略是否生效
它不能替代什么
要明确边界，避免误用：
- 不是 CDN 的“低频回源保护”——CDN 层识别 UV/QPS 是全局统计，Nginx 的 min_uses 是单机局部计数，两者逻辑不同、不可互换
- 不控制缓存查找行为：即使某 URI 还没达到 min_uses 次数，Nginx 仍会查缓存（若存在未过期副本，仍可能 HIT）
- 不解决缓存污染问题：若 cache_key 设计不合理（例如混入 Cookie），即便设为 5，每个用户也会生成独立缓存项，毫无热度可言
