proxy_cache_min_uses 不直接过滤请求，而是设缓存准入门槛：同一URI需被重复访问指定次数后才写入磁盘缓存，从而减少冷请求导致的无效磁盘I/O、僵尸文件及索引开销。
Nginx 的 proxy_cache_min_uses 指令本身**不直接过滤请求**，也不主动拒绝或丢弃低频请求，它的作用是**控制缓存准入门槛**：只有当某个请求的 URI（在满足其他缓存条件的前提下）被重复访问达到指定次数后，Nginx 才会将其响应写入磁盘缓存。这间接减少了无效缓存写入，从而降低磁盘 I/O 压力。
它如何减少磁盘 IO？
默认情况下，只要响应符合缓存条件（如状态码、头信息允许），Nginx 会在第一次请求时就将响应写入缓存目录（可能触发磁盘写入、文件创建、元数据更新等）。对于大量只访问一次的“冷请求”（例如爬虫试探、错误链接、个性化临时页），这种立即缓存毫无价值，反而造成：
- 不必要的磁盘写操作（尤其是小文件高频写入）
- 缓存目录中堆积大量无人再访的“僵尸文件”
- 后续
proxy_cache_path的清理（inactive）和索引维护开销增大
典型配置方式与生效逻辑
该指令需在 location 或 server 块中配合 proxy_cache 使用：
location /api/ {<br> proxy_pass https://backend;<br> proxy_cache my_cache;<br> proxy_cache_min_uses 3;<br> proxy_cache_valid 200 5m;<br>}
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
含义是：同一个 URI（如 /api/user/123）必须在缓存有效期内被**连续或非连续地命中 3 次**（每次均返回可缓存响应），第 3 次响应才会真正落盘；前两次仍走上游，不写缓存。注意：
- 计数基于同一 cache key（默认是
$scheme$proxy_host$request_uri），受proxy_cache_key影响 - 计数在 worker 进程内存中维持，**不跨进程共享**，重启后清零
- 仅影响“写缓存”，不影响“读缓存”——已缓存的内容仍可被后续请求直接命中
搭配使用效果更佳的指令
单靠 proxy_cache_min_uses 不足以全面优化 IO，建议组合以下设置：
-
proxy_cache_valid：严格限制不同状态码的缓存时长，避免长期滞留低价值内容 -
proxy_cache_path ... inactive=10m：及时清理 10 分钟内未被访问的缓存项，释放空间 -
proxy_cache_lock on：防止相同未缓存 URI 被多个并发请求同时回源，减少上游压力及重复写缓存尝试 -
proxy_cache_use_stale updating：在后台更新缓存时，仍可返回旧缓存，提升响应稳定性
需要注意的边界情况
该机制对以下场景效果有限或需额外处理：
- URI 中含随机参数（如
?t=123456789）会导致 cache key 不一致，无法累积计数 → 应用proxy_cache_key剔除干扰参数 - 用户身份相关接口（如带 token 或 session 的请求）天然低频且不可共享 → 不应缓存，优先用
proxy_no_cache或响应头Cache-Control: private显式禁用 - 首次请求仍需完整回源并构造响应，只是不落盘 —— 网络和上游压力并未降低
