proxy_cache_min_uses 通过延迟缓存落盘（如设为2）减少低频请求对SSD的无效写入，配合proxy_cache_lock、inactive调优、404禁缓存等闭环措施，可显著降低小文件随机写频次与磨损。
proxy_cache_min_uses 本身不拦截请求，也不阻止回源，但它能有效减少低频静态请求对 SSD 磁盘的无效写入——关键在于“只在第 N 次请求时才落盘”，从而大幅降低长尾 URL 触发的随机小文件写操作频次。SSD 的擦写寿命有限，高频、分散、不可复用的小缓存文件（如带随机参数的图片 URL、错误路径 favicon.ico）正是磨损主因。
为什么低频静态请求特别伤 SSD
默认 proxy_cache_min_uses 1 时，每个首次访问的静态资源（哪怕只被加载一次）都会生成一个独立缓存文件：可能只有几 KB，却要占用 inode、触发一次 fsync、写入两级目录（如 levels=1:2），并长期滞留在磁盘上直到 inactive 超时。这类请求常见于：
- 前端埋点拼错的图片路径（/img/banner_v2_abcd123.jpg）
- 带时间戳或版本号的调试资源（/css/app.css?v=20260430.1）
- 爬虫扫描的不存在静态文件（/robots.txt.bak、/wp-config.php）
- 浏览器自动请求的 /favicon.ico 或 /apple-touch-icon.png（路径错误时返回 404，但响应仍可能被缓存）
如何用 min_uses 实际降低 SSD 写压力
核心思路是：让真正有复用价值的静态资源尽快入缓存，而把试探性、单次性、错误构造的请求“挡在落盘之前”。操作要点如下：
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
-
静态资源路径单独配置 location，避免全局设值误伤中频内容。例如：
location ~* \.(js|css|png|jpg|gif|webp|woff2?)$ {
proxy_cache_min_uses 2;
} - 设为 2 是性价比最高的起点：过滤掉大量单次爬虫抓取和误点行为，又不显著延迟真实用户二次加载（如刷新页面、新开标签）；设为 3 可进一步收紧，但需观察命中率是否下降
- 配合 proxy_cache_key 剔除干扰参数：确保 $args 不混入随机值。推荐使用 $uri 或 $scheme$host$uri 作为 key 主干，避免 $request_uri 或完整 $args
- 对明确不该缓存的请求，直接 bypass：比如含 debug=1、_t=、utm_ 等参数的资源，用 proxy_cache_bypass $arg_debug $arg_t 跳过整个缓存流程，不参与 min_uses 计数
验证是否真正在保护 SSD
不要只看缓存大小，重点监控写入行为是否收敛：
- 查磁盘写入频率：运行 iostat -x 1，观察 %util 和 w/s（每秒写操作数）是否在流量高峰后明显回落
- 统计新缓存文件生成速度：执行 find /path/to/cache -type f -mmin -5 | wc -l（5 分钟内新建文件数），调高 min_uses 后该值应下降 40%+（尤其在爬虫活跃时段）
- 检查缓存文件大小分布：用 find /path/to/cache -type f -size -4k | wc -l 统计小文件占比，若 >60%，说明大量无效碎片在持续刷盘
- 看 X-Cache-Status 响应头：真实流量中出现大量 MISS (min_uses) 状态（Nginx 1.23+ 支持），即表示请求已识别但尚未达标，正被主动“延迟缓存”
必须同步启用的关键防护
仅调高 min_uses 不足以保护 SSD，还需闭环配置：
- proxy_cache_lock on：防止前 N−1 次未缓存请求并发回源，引发重复生成相同响应、多次写盘
- inactive=10m（而非默认 10s）：让短暂存活的缓存更快释放空间，避免小文件堆积
- max_size 合理设限 + 使用 tmpfs（/dev/shm）：将缓存挂载到内存临时文件系统，彻底规避 SSD 写入（适用于中小规模静态资源）
- 对 404/403 响应显式禁用缓存：通过 proxy_no_cache $upstream_http_content_type $upstream_status 配合 map，确保错误响应永不落盘
