proxy_cache_min_uses是保护ssd缓存盘寿命的关键配置，通过设定请求复用阈值过滤低频无效写入，需结合proxy_cache_lock、inactive及监控形成闭环防护。

proxy_cache_min_uses 是保护 SSD 缓存盘寿命的轻量但关键的一道防线——它不减少请求量，但能显著降低无效写入频次。SSD 的擦写次数（P/E cycles）有限，而大量长尾请求（如爬虫试探、404 路径、带随机参数的埋点）若每次响应都落盘，会快速消耗磁盘寿命，且几乎不带来命中收益。

识别正在侵蚀 SSD 的低频请求

真正威胁 SSD 寿命的是“高频出现 + 单次写入 + 零复用”的请求组合。可通过三类现象快速定位：

• 缓存目录下小文件数量激增（find /var/cache/nginx/my_cache -type f | wc -l 每小时增长超 500），但 du -sh 显示总容量增长缓慢——说明大量 KB 级无效文件在反复创建删除
• access_log 中大量 404/502 请求（如 /wp-login.php、/phpmyadmin/index.php）却出现在缓存路径中（查对应文件 mtime 可确认）
• 开启 add_header X-Cache-Status $upstream_cache_status 后，持续观察到高比例 MISS 且几乎无 EXPIRED 或 STALE ——说明缓存项写入后从未被再次访问

设置合理 min_uses 值以降低 SSD 写放大

目标不是“杜绝写入”，而是让写入集中在有复用价值的请求上。数值需按路径语义分层设定：

aperture: the L402 aware reverse proxy

安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。

下载

• 静态资源（.js/.css/.png/.woff2）：设为 2。真实用户二次加载概率高，设为 2 可过滤掉单次爬虫抓取和 CI 构建预览等噪声
• 首页 HTML、公共 API 入口（如 /api/config）：保持 1。天然高复用，早写入反而节省后续读取延迟
• 带用户 ID 或会话态的路径（如 /user/123、/api/order?uid=456）：设为 2～3，匹配真实回访行为；同时必须精简 proxy_cache_key，剔除干扰参数
• 含时间戳/随机串的接口（如 /log?ts=1744624800&r=abc123）：不依赖 min_uses，直接用 proxy_no_cache 1 或 proxy_cache_bypass $arg_r 跳过整个缓存流程

必须搭配 proxy_cache_lock 才避免 SSD 白写

只调高 min_uses 不加锁，会导致同一 URI 的前 N−1 次请求并发回源、各自生成临时响应并尝试写缓存（即使未达阈值，Nginx 仍可能触发部分索引更新或日志记录），加剧 SSD 写入压力。正确做法是：

• 启用 proxy_cache_lock on，并设 proxy_cache_lock_timeout 3s（略大于后端 P95 响应时间）
• 首次请求回源并加锁；后续同 key 请求等待锁释放，不重复回源；锁释放后响应统一写入一次缓存——此时才真正满足 min_uses 条件
• 这样既保障了“一次写入、多次服务”，又把原本 N 次潜在写操作压缩为 1 次，直击 SSD 寿命痛点

配合 inactive 和监控形成闭环防护

min_uses 解决“该不该写”，inactive 解决“写了多久不访问就删”。对 SSD 友好配置建议：

• proxy_cache_path ... inactive=15m：比默认 10m 更短，加速清理冷数据，减少 SSD 上长期驻留的无效文件
• 通过 nginx_stub_status 或 Prometheus 监控 ngx_http_proxy_module_cache_miss_rate，若该指标持续 >85%，说明 min_uses 设置过高或 cache_key 设计不合理
• 定期用 awk '{print $7}' access.log | sort | uniq -c | sort -nr | head -20 检查 URI 分布，验证长尾占比是否下降