proxy_cache_min_uses 控制uri响应体写入缓存的触发次数，默认1次即写；设为n则前n-1次不缓存，第n次起才写入并服务后续请求，影响缓存空间效率与命中率，但不干预回源、读缓存或客户端行为。
proxy_cache_min_uses 的核心作用不是“拦截”请求，而是控制“缓存写入时机”。它不阻止请求到达后端，也不减少磁盘 IO 的发生次数，但能有效避免低频请求把响应反复写入磁盘，从而节省磁盘空间和写入带宽。
它到底管什么、不管什么
该指令只决定一个 URI（按 proxy_cache_key 计算）的响应体是否落盘到缓存区。默认值为 1，意味着第一次请求就写缓存；设为 2，则前一次响应不存，第二次才存；设为 3，则前两次都不存，第三次起才开始缓存并服务后续请求。
- ✅ 影响：是否将响应体写入共享内存与磁盘缓存区
- ✅ 影响：缓存空间占用效率和命中率长期表现
- ❌ 不影响：请求是否转发给后端（所有请求照常回源）
- ❌ 不影响：是否读取已有缓存（已缓存项仍可正常 HIT）
- ❌ 不影响：CDN 层或客户端的请求发起行为
为什么设高了反而伤性能
盲目提升 proxy_cache_min_uses 全局值（比如统一设成 5），会让大量中频请求（每天访问 2–4 次）永远达不到阈值，导致它们既无法被缓存，又持续穿透回源——这不仅没省下磁盘 IO，还加重了后端压力和网络延迟。
- 静态资源（.js/.css/.png）适合设为 2～3：过滤掉爬虫试探、单次调试等噪声
- 用户资料页（/api/user/123）若具备访问聚集性，也可设为 2
- 带时间戳、随机参数的埋点接口（如 /log?ts=1744624800&r=abc123）应直接跳过缓存模块，而非依赖 min_uses 过滤
- 首页 HTML 或公共 JS 包这类强复用内容，保持 min_uses 1 更合理
配合 CDN 降低源站冲击的实用组合
单靠 Nginx 的 min_uses 无法替代 CDN 的智能低频识别能力。真正有效的策略是分层协同：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- CDN 层对静态资源设置强缓存（Cache-Control: public, max-age=31536000），让边缘节点承担绝大部分请求
- 对动态接口显式设 no-cache 或短 TTL（如 60s），避免 CDN 缓存低价值响应
- Nginx 源站侧按 location 分路径配置 min_uses：高复用路径设为 2，低价值路径用 map 或 if 跳过 proxy_cache 指令
- 优化 cache key：剔除 $args 中不可缓存参数（如 utm_source、_t），或用 proxy_cache_bypass $arg_nocache 显式绕过
验证是否生效的小技巧
在 location 块中加上这一行，便于观察缓存行为：
add_header X-Cache-Status $upstream_cache_status;
请求返回头中会出现：
- MISS：缓存未命中，且本次响应会写入缓存（min_uses=1 时首次即写；min_uses=2 时第二次才写）
- HIT：命中有效缓存，直接返回
- BYPASS：因 proxy_cache_bypass 或 proxy_no_cache 规则未走缓存
- 注意：MISS 并不等于没缓存——若 min_uses=2，第一次请求也是 MISS，但不会写缓存
