proxy_cache_min_uses 用于过滤试探性请求，规定资源被缓存前需被相同 URI 请求的最小次数，防止爬虫、错误URL等低频请求污染缓存；需结合日志分析、cache_status监控及proxy_cache_key等指令协同优化。
proxy_cache_min_uses 的作用不是缓存“热门”，而是过滤“试探性请求”
这个指令定义一个资源被代理缓存前，必须被相同 URI 请求的最小次数。它不直接判断“是否热门”，而是防止一次性、低概率、扫描式或错误配置引发的请求污染缓存空间。比如，爬虫抓取大量不存在的图片路径（/uploads/2023/12/xxx_foo_bar_v2_thumb.jpg），或前端拼错 URL 导致 404，这些请求若直接进缓存，会生成大量低效 cache key，占用内存且无法复用。
识别“长尾”请求：从日志和缓存命中率入手
真正需要过滤的是那些高频出现但单个 URI 请求次数极低、总体占比高、缓存命中率趋近于 0 的请求集合。可通过以下方式定位：
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
- 用 log_format 记录 $request_uri 和 $status，配合 awk + sort + uniq 统计 URI 出现频次，筛选出出现 1–3 次却占总请求数 30%+ 的 URI 分布
- 开启 proxy_cache_status 头（如
add_header X-Cache-Status $upstream_cache_status;），在真实流量中采样，观察 MISS 占比异常高的时间段，再反查对应 URI 特征 - 检查 proxy_cache_path 配置中的
inactive=时间，若大量缓存条目在几秒内就被淘汰，说明它们几乎从未被再次访问 —— 这正是 min_uses 应该拦截的对象
合理设置 min_uses 值：平衡冷启动延迟与缓存健康度
值太小（如 1）等于关闭过滤；值太大（如 10）会让真正“慢热”的资源长期无法入缓存。推荐策略：
- 新上线服务或 CDN 替换初期，先设为 3，观察 24 小时内缓存填充速度与 MISS 率变化
- 若静态资源（JS/CSS/字体）命中率稳定在 85%+，可尝试调至 2；若图片类资源长尾明显（如用户上传头像路径唯一），保持 3–5 更稳妥
- 对带随机参数的请求（如
?v=123456或 A/B 测试标识），应配合 proxy_cache_key 剔除干扰参数，否则 min_uses 失效 —— 同一资源因参数不同被视为多个 URI
配合其他指令，形成缓存准入闭环
min_uses 只是第一道门，需与其他机制协同：
- 用 proxy_cache_bypass $arg_nocache 显式绕过调试请求，避免它们参与计数
- 对 4xx/5xx 响应，通过 proxy_cache_valid 404 1m 限制错误响应缓存时长，防止死链长期驻留
- 结合 proxy_ignore_headers Cache-Control Expires（谨慎使用）或 proxy_cache_valid 显式定义有效时间，避免上游乱设 header 导致缓存行为失控
