Nginx 中 proxy_cache_min_uses 实战调优：有效拦截长尾请求对缓存空间的无效挤占-Nginx-PHP中文网

proxy_cache_min_uses控制响应体是否写入缓存，仅影响落盘行为，不拦截请求或阻止命中；默认1次即缓存，设为n则需n次访问后才开始缓存，计数基于proxy_cache_key。

nginx 中 proxy_cache_min_uses 实战调优：有效拦截长尾请求对缓存空间的无效挤占

proxy_cache_min_uses 不是拦截请求，而是决定“这次响应值不值得落盘”。它不会让请求不发往后端，也不会阻止缓存命中——但它能实实在在减少低频 URI 对磁盘空间和写入带宽的无效占用。

`proxy_cache_min_uses` 到底控制什么行为

它只影响「响应体是否写入共享内存 + 磁盘缓存区」，不影响请求转发、缓存查找或客户端行为
默认值是 1：第一次访问就缓存；设为 2，则前一次响应不落盘，第二次才开始缓存并服务后续请求
已存在的缓存项仍可正常 HIT，哪怕该 URI 还没达到 min_uses 次数
计数依据是 proxy_cache_key（不是原始 URI），所以若 key 中包含随机参数（如 $arg_r），计数会分散失效

常见误判现象：

配置了 proxy_cache_min_uses 2，但始终看到 X-Cache-Status: MISS → 很可能是 proxy_cache_key 每次都不同，导致计数无法累积
日志里大量 MISS 且无 EXPIRED 或 STALE → 并非缓存失效，而是根本没写进去

哪些路径适合调高 `proxy_cache_min_uses`

静态资源（.js / .css / .png）：设为 2 或 3 能过滤掉爬虫试探、单次调试、CI 构建预览等噪声请求
用户资料页（如 /api/user/123）：若业务上存在访问聚集性（比如某用户突然被转发爆火），2 是合理起点
首页 HTML 或公共 JS 包：保持 1 更合适——它们天然复用率高，早缓存早受益
带时间戳/随机参数的埋点接口（如 /log?ts=1744624800&r=abc123）：不该靠 min_uses 过滤，而应直接跳过缓存模块，否则 cache key 泛滥反而拖慢 lookup

关键原则：

不要全局统一设高值（比如全站 proxy_cache_min_uses 5）
中频请求（日均 2–4 次）一旦卡在阈值外，就会持续回源，既没省 IO，又加重后端压力

和 `proxy_cache_lock` 配合才能真正防雪崩

proxy_cache_min_uses 单独设高，只是“延迟写缓存”，但并发请求仍会同时打到后端。必须搭配 proxy_cache_lock on 才能起效：

aperture: the L402 aware reverse proxy

安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。

下载

当首个请求触发回源时，后续同 key 请求会被阻塞（默认最多等 5s）
若这期间第一个请求完成并写入缓存，后续请求就能直接 HIT，自然满足 min_uses=2 的条件
否则超时后，第二个请求也会回源——所以 proxy_cache_lock_timeout 要略大于后端平均响应时间

典型配置片段：

location ~* \.(jpg|jpeg|png|gif|css|js)$ {
    proxy_cache static;
    proxy_cache_valid 200 1d;
    proxy_cache_min_uses 2;
    proxy_cache_lock on;
    proxy_cache_lock_timeout 3s;
    proxy_pass https://origin;
}

注意：proxy_cache_lock 仅对未缓存的请求生效，已缓存项不受影响。

容易被忽略的验证盲区

$upstream_cache_status 只反映本次是否命中/写入，不反映计数进度。你无法从响应头知道“这个 URI 目前已被访问几次”
查看计数状态只能靠日志 + 自定义变量（Nginx 开源版不暴露内部计数器），实际运维中建议：
- 先用 add_header X-Cache-Status $upstream_cache_status 观察 MISS / HIT 分布
- 再结合 access log 统计特定 URI 的访问频次（如 awk '{print $7}' access.log | sort | uniq -c | sort -nr | head -20）
- 若某类资源 MISS 极高但实际 PV 很低，说明 min_uses 设得偏高或 cache_key 设计不合理