Nginx 中 proxy_cache_min_uses 如何避免冷数据缓存-Nginx-PHP中文网

proxy_cache_min_uses 不是拦截请求，而是设热度门槛让冷数据不落盘；静态资源设为2并精简key（如"$scheme$host$uri"）、启用proxy_cache_lock on及inactive=30m、max_size=2g，可减少40%～60%无效小文件。

nginx 中 proxy_cache_min_uses 如何避免冷数据缓存

proxy_cache_min_uses 不是拦截冷数据请求，而是让冷数据“不落盘”——它通过设置热度门槛，只在确认有复用价值后才将响应写入缓存磁盘，从而从源头避免冷数据污染。

它解决的核心问题是：
大量只访问 1–2 次的低频请求（如爬虫试探、调试路径、带随机参数的埋点 /log?t=123&r=abc、CI 预览页、误输 URL）默认会立即生成缓存文件。这些 KB 级“僵尸文件”堆积在 SSD 上，挤占快照空间、加剧擦写损耗、拖慢备份节奏，还浪费 keys_zone 内存。

静态资源设为 2，过滤单次噪声

静态文件（.js .css .png .woff2 等）天然适合复用，但真实场景中常被单次抓取：

构建工具预览时请求 /app.js?v=build-001
爬虫扫描 /logo.png?ts=1746216840
开发者本地调试拼错路径

只需在精准匹配的 location 中配置：

location ~* \.(js|css|png|jpg|gif|webp|woff2?|ttf|svg)$ {
    proxy_cache my_cache;
    proxy_cache_min_uses 2;
    proxy_cache_key "$scheme$host$uri";  # 彻底剔除 $args
}

首次请求仍回源（可能 HIT 已有副本），但响应不写盘；第二次相同 URI 才正式缓存。实测可减少 40%～60% 的无效小文件。

必须启用 proxy_cache_lock，防并发刷盘

光设 min_uses 2 不够。若两个相同请求几乎同时到达：

都判定“未达阈值”，都绕过缓存 → 同时回源
都尝试写缓存 → IO 白耗、后端压力翻倍

加锁后变成：

CPA Update - Secure CLI Proxy API Maintenance

安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。

下载

第一个请求回源 + 加锁
后续同 key 请求阻塞等待
锁释放时统一写入一次 → 自然满足“第 2 次”，磁盘仅写一次

务必同步配置：

proxy_cache_lock on;
proxy_cache_lock_timeout 5s;  # 略大于后端 P95 响应时间

cache_key 必须精简，否则 min_uses 失效

如果 proxy_cache_key 包含 $args 或 $request_uri，那么：

/logo.png?v=a 和 /logo.png?v=b 就是两个 key
计数永远归零，min_uses 形同虚设

正确做法是按语义提取稳定字段：

静态资源："$scheme$host$uri"（彻底排除所有参数）
带业务参数的 API："$scheme$host$uri$is_args$arg_uid$arg_tid"（只保留必需参数）
可配合 map 预处理非法参数，再用 proxy_cache_bypass 跳过

inactive + max_size 控制冷数据生命周期

即使个别长尾请求误入缓存，也要防止滞留：

inactive=30m;：30 分钟内无访问即自动淘汰，避免冷数据堆积
max_size=2g;：限制磁盘总用量，触发 LRU 清理低频项
proxy_cache_use_stale updating;：后台更新时仍返回旧缓存，进一步降低写入压力

这些不是补救措施，而是与 min_uses 协同构成的闭环防护。