proxy_cache_min_uses 控制响应第几次才写入磁盘缓存，核心是避免无用请求生成小文件、减少SSD磨损和inode消耗；需按路径分层配置、精简cache_key、启用cache_lock，并结合日志与X-Cache-Status验证效果。

proxy_cache_min_uses 不是过滤器，它不拒绝、不拦截、不跳过请求，而是控制“第几次响应才写入磁盘缓存”。真正起效的方式，是让那些只访问一次、参数随机、路径无效的请求，永远达不到写入门槛，从而避免生成大量无用小文件、减少 SSD 写入磨损和 inode 消耗。

关键不在“设多大”，而在“怎么分层配、配给谁、配了之后怎么验证”。

---

识别哪些请求该被“延迟写入”

先别急着改配置，先看日志确认问题是否存在：

• 统计 URI 频次：

  awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20

  如果大量 URI 只出现 1～2 次，却占总请求数 20% 以上，就是典型长尾。

• 看缓存状态：
  在 location 块中加：

  add_header X-Cache-Status $upstream_cache_status;

  观察响应头。若大量 MISS 且长期不转 HIT 或 EXPIRED，说明这些 URI 几乎从不复用。

• 典型该延迟写入的请求包括：

  • 带随机参数的埋点（/log?r=abc&t=1744624800）
  • 扫描路径（/phpmyadmin/、/wp-config.php.bak）
  • 拼错资源（/static/js/app_v2.min.js 实际应为 app_v2.1.min.js）
  • 返回 404/204 的接口（如 /api/user/999 未登录用户查不到）

这些请求落盘毫无价值，反而加速磁盘老化。

---

按路径类型分层设置 min_uses

全局统一设值（比如全站设成 5）会误伤中频资源，导致后端压力反升。必须按语义拆开配：

• 静态资源（JS/CSS/图片/字体）

  location ~* \.(js|css|png|jpg|gif|webp|woff2?)$ {
      proxy_cache my_cache;
      proxy_cache_min_uses 2;
      proxy_cache_valid 200 1d;
      proxy_cache_lock on;
      proxy_cache_lock_timeout 5s;
  }

  设为 2 足够过滤单次爬虫抓取或调试请求，保留真实用户二次加载行为。

• 首页、公共配置、强复用接口

  

  CPA Update - Secure CLI Proxy API Maintenance

  安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。

  下载

  location = / {
      proxy_cache my_cache;
      proxy_cache_min_uses 1;  # 首次即缓存，无需预热
  }
  location /api/config {
      proxy_cache my_cache;
      proxy_cache_min_uses 1;
  }

• 带 ID 的动态接口（如 /api/article/123）
  若业务存在回访聚集（如某文章被转发后短时间内多人访问），可设为 2 或 3；
  若 ID 分散且无聚集性，优先精简 proxy_cache_key（剔除 $args 中干扰参数），再设值。

• 埋点、上报、心跳类接口

  location ~ ^/(log|track|beacon|ping) {
      proxy_cache off;  # 或 proxy_no_cache 1;
      proxy_pass https://backend;
  }

  这类请求根本不该进缓存流程，靠 min_uses 过滤是本末倒置——key 泛滥会让计数失效，还拖慢 lookup。

---

必须配套的关键配置

只调 min_uses 是半套方案，以下三项缺一不可：

• 开启缓存锁

  proxy_cache_lock on;
  proxy_cache_lock_timeout 5s;

  否则前 n−1 次请求会并发回源，白白增加后端压力，还可能重复写缓存（虽未达标，但尝试仍耗 IO）。

• 精简 proxy_cache_key
  默认 key 包含 $request_uri，只要参数稍有不同（如 ?utm_source=a vs ?utm_source=b），就视为不同 key，min_uses 计数无法累积。
  推荐写法：

  proxy_cache_key "$scheme$request_method$host$uri$is_args$arg_id$arg_type";

  显式剔除 utm_*、_t、r= 等随机参数。

• 配合 inactive 清理与状态监控

  proxy_cache_path /var/cache/nginx/my_cache levels=1:2 keys_zone=my_cache:100m inactive=10m use_temp_path=off;

  inactive=10m 能及时清理冷数据；上线后用 find /var/cache/nginx/my_cache -type f | wc -l 对比调参前后文件增长速度。

---

验证是否真在起作用

• 查看响应头 X-Cache-Status：

  • MISS（未命中且本次未写入）→ 很可能是未达 min_uses
  • HIT → 已缓存并返回
  • BYPASS → 被 proxy_no_cache 或 proxy_cache_bypass 显式绕过

• 监控磁盘写入变化：

  # 统计 5 分钟内新建缓存文件数
  find /var/cache/nginx/my_cache -type f -mmin -5 | wc -l

  调优后应明显下降（实测静态资源路径设为 2，日均写入量可降 40%～60%）。

• 注意：计数是单机内存内维持，不跨 worker、不跨实例。4 台 Nginx 上同一 URI 各自要达到阈值才能缓存——这不是缺陷，而是设计使然。