proxy_cache_min_uses不是缓存开关，只控制第几次响应才写入磁盘和共享内存；设为2或3可过滤“高频出现+单次写入+零复用”的长尾请求，需按路径语义分层配置、精简cache_key、启用proxy_cache_lock，并通过x-cache-status和缓存文件增量验证效果。
proxy_cache_min_uses 不是缓存开关，也不拦截请求，它只决定“第几次响应才真正写入磁盘和共享内存”。设为 2 或 3，能让 Nginx 拒绝把单次访问的冷数据落盘，从而从源头减少无效缓存条目，释放 keys_zone 内存和物理磁盘空间。
识别真正该过滤的长尾请求
不是访问少就要拦，关键看是否具备“高频出现 + 单次写入 + 零复用”特征：
- URI 高度离散：比如
/log?t=1744624800&r=abc123、/wp-login.php、含 UUID 的调试路径 - 日志中大量 MISS，却几乎不转为 HIT 或 EXPIRED，且对应缓存文件几秒内就被 inactive 清理
- 缓存目录下 KB 级小文件数量激增，但总容量增长缓慢——说明全是“写一次就丢”的僵尸文件
- 大量 404、204、302 响应集中在某些路径，表明这些请求本身无业务价值
按路径语义分层设置 min_uses 值
全局统一设值容易误伤中频内容，应在 location 块中差异化配置：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
-
静态资源（.js/.css/.png/.woff2）：设为
2。过滤爬虫抓取、CI 预览、调试请求，保留真实用户二次加载场景 -
首页 HTML、公共 API（如 /、/api/config）：保持
1。天然高复用，首次缓存即有价值 -
带用户标识路径（如 /user/123、/order?id=456）：设为
2或3，匹配回访行为；但必须先精简proxy_cache_key，剔除会话类干扰参数 -
含时间戳/随机串的上报接口（如 /track、/beacon）：不用 min_uses，改用
proxy_no_cache 1或proxy_cache_bypass $arg_r $arg_t直接绕过整个缓存模块
必须搭配 proxy_cache_lock 才防重复写盘
只设 min_uses 2 而不加锁，前两次同 key 请求仍会并发回源，可能触发临时索引更新或日志记录，反而增加 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 分钟增量变化 - 检查 keys_zone 内存占用率变化，以及
$upstream_cache_status在 access log 中的分布比例
