如何利用 proxy_cache_min_uses 过滤冷数据节省磁盘空间指南-Nginx-PHP中文网

proxy_cache_min_uses 是缓存写入的热度门槛，设为3时前两次请求不落盘，第三次才写入；需结合精简cache_key、proxy_cache_lock及inactive/max_size等配置协同生效。

如何利用 proxy_cache_min_uses 过滤冷数据节省磁盘空间指南

proxy_cache_min_uses 不是过滤器，而是缓存写入的“热度门槛”——它让冷数据根本落不了盘，从而从源头节省磁盘空间。设为 3，意味着同一资源前两次请求照常回源、不生成任何缓存文件；第三次起才真正写入磁盘并服务后续命中。关键不在“拦请求”，而在“省写入”。

真正需要拦截的不是访问量少的资源，而是具备以下特征的“伪冷数据”：

URI 高度离散：如 /log?t=1746216840123&r=abc、/api/order?uid=123&v=4.2.1&ts=1713456000，每次参数微调就生成新 key
单次生命周期：日志中大量 URI 仅出现 1–2 次，但占总请求数 20% 以上
命中率趋近于零：$upstream_cache_status 长期为 MISS，且几乎不转为 HIT 或 EXPIRED
无效响应占比高：404、204、302 重定向等非 200/301 类响应频繁出现在这些路径

全局统一设值容易误伤高频内容，也防不住真正长尾。应结合语义在 location 块中差异化配置：

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

下载

静态资源（.js/.css/.png/.woff2）：设为 2 —— 过滤爬虫单次抓取、CI 构建预览、调试路径，保留真实用户二次加载行为
首页 HTML 或公共接口（/、/api/config）：保持 1 —— 天然高复用，首次即缓存更合理
带用户标识的详情页（/user/123、/article/456）：设为 2 或 3 —— 匹配真实回访规律，避免冷启动后立即占位
含随机参数的上报接口（/track、/beacon、/log）：不依赖 min_uses，改用 proxy_no_cache 1 或 proxy_cache_bypass $arg_r $arg_t 直接跳过整个缓存模块

单独调高 min_uses 效果有限，甚至引发重复回源和写放大。以下三项必须同步启用：

精简 proxy_cache_key：剔除干扰字段，例如用 $scheme$host$uri 替代 $request_uri，用 $arg_uid 替代 $args，确保相同语义请求归为一类
启用 proxy_cache_lock on：防止前两次同 key 请求并发打到后端。第一次回源加锁，第二次等待并顺带获取结果，自然满足 min_uses 条件后只写一次盘
配合 inactive 和 max_size 约束生命周期：例如 inactive=10m 加速淘汰未达阈值又无人再访的临时条目，max_size=2g 防止缓存无序膨胀

不能只看配置是否生效，要观察实际行为指标：

在响应头中添加：add_header X-Cache-Status $upstream_cache_status;，采样分析 MISS 集中路径是否与预期冷数据一致
监控缓存目录小文件增长：find /var/cache/nginx/my_cache -type f -mmin -60 | wc -l，对比调整前后每小时新建文件数是否明显下降
检查 keys_zone 内存占用稳定性：若内存使用率不再随流量线性上涨，说明冷 key 不再持续注入
日志中统计 $upstream_cache_status 字段，若某类路径长期 MISS 且无后续 HIT/EXPIRED，说明 min_uses 正在有效跳过写入