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 的请求集合。可通过以下方式定位：

• 用 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）会让真正“慢热”的资源长期无法入缓存。推荐策略：

WebChat Voice Proxy

⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**

下载

• 新上线服务或 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 导致缓存行为失控