如何配置 `proxy_cache_min_uses` 过滤不常用的请求-Nginx-PHP中文网

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

如何配置 `proxy_cache_min_uses` 过滤不常用的请求

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 各自要达到阈值才能缓存——这不是缺陷，而是设计使然。