Nginx中proxy_cache_min_uses指令过滤低频请求减少磁盘IO-Nginx-PHP中文网

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

proxy_cache_min_uses 不直接过滤请求，而是设缓存准入门槛：同一uri需被重复访问指定次数后才写入磁盘缓存，从而减少冷请求导致的无效磁盘i/o、僵尸文件及索引开销。

nginx中proxy_cache_min_uses指令过滤低频请求减少磁盘io

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>}

含义是：同一个 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 显式禁用
首次请求仍需完整回源并构造响应，只是不落盘 —— 网络和上游压力并未降低