proxy_cache_min_uses需分层配置并配合proxy_cache_lock：静态资源设2，首页/api保持1，用户路径设2–3，上报接口用proxy_no_cache；启用锁防并发回源，通过x-cache-status和文件增量验证效果。
直接设高 proxy_cache_min_uses 不会自动“过滤请求”，但它能有效阻止低频资源写入磁盘——只有达到指定访问次数的请求，响应体才真正落盘。这从源头减少缓存文件数量，避免小文件堆积和空间浪费。
识别该拦截的低频长尾请求
不是访问少就要拦，关键是找那些“高频出现 + 单次写入 + 零复用”的请求：
- URI 高度离散：比如
/log?t=1744624800&r=abc123、/wp-login.php、带 UUID 的调试路径 - 日志中大量
MISS但几乎不转为HIT，且对应缓存文件几秒内就被inactive清理 - 缓存目录下小文件（KB 级）数量激增，但总容量增长缓慢——说明全是“写一次就丢”的僵尸文件
按路径类型分层设置 min_uses 值
一刀切设成 5 或 10 容易误伤真实中频内容，应结合语义和复用规律配置：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
-
静态资源（.js/.css/.png/.woff2）：设为
2。真实用户二次加载概率高，设 2 可过滤掉单次爬虫抓取、CI 预览、调试请求 -
首页 HTML、公共 API（如
/api/config）：保持1。天然高复用，首次缓存即有价值 -
带用户标识的路径（如
/user/123、/order?id=456）：设为2或3，匹配真实回访行为；但必须先精简proxy_cache_key，剔除会话类干扰参数 -
含时间戳/随机串的上报接口（如
/track?r=xxx&t=1744624800）：不靠min_uses，改用proxy_no_cache 1或proxy_cache_bypass $arg_r $arg_t直接绕过整个缓存模块
必须搭配 proxy_cache_lock 才防重复写盘
只设 min_uses 2 而不加锁，前两次同 key 请求仍会并发回源，Nginx 可能触发临时索引更新或日志记录，反而增加 SSD 写压力：
- 启用
proxy_cache_lock on，并设proxy_cache_lock_timeout略大于后端 P95 响应时间（例如3s或5s） - 第 1 次请求回源 + 加锁；第 2 次请求等待锁释放，不重复回源；锁释放后统一写入一次缓存——此时自然满足
min_uses=2 - 后续所有请求直接
HIT，零磁盘写入
验证是否真在节省磁盘空间
别只看配置，要观察实际效果：
- 开启响应头：
add_header X-Cache-Status $upstream_cache_status;，重点监控哪些路径长期MISS却无后续HIT - 统计缓存目录新建文件数：
find /var/cache/nginx/my_cache -type f -mmin -5 | wc -l，对比调参前后 5 分钟增量变化 - 检查日志中
$upstream_cache_status字段，若某类路径MISS占比下降、HIT上升，同时缓存目录总文件数增速放缓，说明生效
