proxy_cache_min_uses 是缓存写入门槛，决定同一 key 第几次访问才写入磁盘，用于过滤低频长尾请求以节省空间、降低 SSD 磨损；需结合 proxy_cache_lock、精简 proxy_cache_key 及按路径语义分层配置。
proxy_cache_min_uses 不是过滤器，而是一道“缓存写入门槛”——它不拦截请求、不跳过回源，只决定同一个缓存 key 第几次访问才真正把响应体写进磁盘。它的核心价值，在于让低频长尾请求压根不生成缓存文件，从而节省磁盘空间、降低 SSD 写磨损、减少小文件碎片。
哪些请求该被“延迟缓存”？先识别真长尾
不是访问少就要拦，关键是找那些高频出现 + 单次写入 + 零复用的请求：
- URI 高度离散：比如
/log?t=1744624800&r=abc123、/wp-login.php、/debug/uuid-xxxx - 日志里大量
MISS，但几乎从不转为HIT，对应缓存文件几秒内就被inactive清理 - 缓存目录下 KB 级小文件数量猛增，总容量却增长缓慢 → 全是“写一次就丢”的僵尸文件
- 大量 404 或 204 响应，路径本身无业务价值（如爬虫试探、错误埋点）
按路径语义分层设值，拒绝一刀切
全局统一设成 5 或 10 容易误伤中频内容，也放行真实噪声。应在 location 块里差异化配置：
静态资源（
.js/.css/.png/.woff2）：设为2
→ 过滤掉单次爬虫抓取、CI 预览、本地调试，保留用户二次加载行为首页 HTML、公共 API（如
/、/api/config）：保持1
→ 天然高复用，首次缓存即合理，无需预热带用户标识路径（如
/user/123、/order?id=456）：设为2或3
→ 匹配真实回访节奏；但必须先精简proxy_cache_key，剔除sessionid、_t等干扰参数含时间戳/随机串的上报接口（如
/track?r=xxx&t=1744624800）：不用min_uses
→ 直接用proxy_no_cache 1或proxy_cache_bypass $arg_r $arg_t绕过整个缓存模块
必须搭配 proxy_cache_lock，否则前几次仍并发刷盘
只设 proxy_cache_min_uses 2 不够——若无锁，第 1 次和第 2 次请求可能同时回源、各自尝试写缓存，IO 消耗翻倍。
启用锁后才能实现“一次回源、一次写入、多次服务”：
proxy_cache_lock on;
→ 首个请求加锁并回源proxy_cache_lock_timeout 5s;
→ 超时略大于后端 P95 响应时间（如 3s 或 5s）第 2 次同 key 请求阻塞等待，锁释放时统一写入 → 自然满足
min_uses=2
aperture: the L402 aware reverse proxy下载安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
后续所有请求直接
HIT，零磁盘写入
精简 cache_key 是前提，否则 min_uses 形同虚设
如果 proxy_cache_key 包含 $args 或 $request_uri，那 /logo.png?v=abc 和 /logo.png?v=def 就是两个 key，永远达不到计数门槛。
推荐写法：
- 静态资源：
proxy_cache_key "$scheme$host$uri"; - 更稳妥：
proxy_cache_key "$scheme$host$uri$is_args";（彻底排除所有查询参数） - 对带版本号或调试参数的资源：用
proxy_cache_bypass $arg_debug $arg_v直接跳过缓存判断
上线后看效果，别只信配置
加响应头：
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是否因“未达阈值”而非“未命中”
不复杂但容易忽略
