proxy_cache_min_uses 是响应写入缓存的门槛而非命中开关；设为2时首次访问不缓存，第二次才写入并服务第三次起请求；需按资源热度分层设置、精简cache_key、配合proxy_cache_lock及日志头验证。
proxy_cache_min_uses 不是“命中开关”，而是“写入门槛”——它不决定请求能否从缓存读取，只决定响应体是否落盘。设为 2，意味着前一次访问照样回源、照样检查缓存（若已有旧缓存仍可 HIT），但这次响应不存；直到第二次访问，才把响应写进缓存，并服务第三次及之后的请求。
按资源热度分层设值，避免一刀切
全站统一设成 3 或 5 容易误伤中频资源，反而推高后端压力：
-
首页、公共 JS/CSS、配置接口：设为
1。这些内容天然复用率高，首次即缓存能快速建立 HIT 基础，减少冷启动延迟 -
用户头像、商品图、API 数据页：设为
2或3。过滤掉单次爬虫抓取、前端调试或偶然点击，保留真实重复访问行为 -
带随机参数的埋点、上报、扫描路径（如 /phpmyadmin/）：不配
proxy_cache，直接用proxy_no_cache或proxy_cache_bypass跳过整个缓存流程，比依赖 min_uses 更干净
必须配合 cache_key 精简，否则计数失效
min_uses 的计数基于 proxy_cache_key 生成的键。如果 key 包含了时间戳、UUID、utm 参数或 Cookie，同一逻辑资源会生成无数个不同 key，导致永远达不到阈值：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 把
$scheme$host$request_uri改为$scheme$host$uri$is_args$args，再用map清洗参数，例如剔除&t=、&r=、&utm_ - 对登录态敏感的接口，不在 key 中包含
$cookie_sessionid，改用proxy_no_cache $cookie_sessionid主动排除 - 验证方式：在日志中加
$cache_key字段，观察相同业务意图的请求是否生成一致 key
搭配 proxy_cache_lock，让 min_uses 真正生效
没有 lock 时，多个并发请求同时触发 min_uses 计数，可能各自独立计数、各自回源，造成重复穿透和写入竞争：
- 开启
proxy_cache_lock on后，首个请求回源，其余同 key 请求等待；等响应返回并满足 min_uses 条件后，缓存写入完成，后续请求统一 HIT - 建议搭配
proxy_cache_lock_timeout 5s，避免长时间阻塞；再加proxy_cache_use_stale updating，让等待中的请求也能返回旧缓存 - 这对设为 2 的场景尤其关键：第一次请求触发回源 + 锁定，第二次请求到来时，锁未释放完，但只要旧缓存还在，就能用 stale 返回，避免双重延迟
用 X-Cache-Status 和日志交叉验证效果
光改配置没用，得看实际行为是否符合预期：
- 在 location 中加
add_header X-Cache-Status $upstream_cache_status;，观察响应头：连续两次请求，第一次是MISS，第二次变成HIT或EXPIRED，说明 min_uses 生效 - 查 access.log，筛选出
$upstream_cache_status为MISS的 URI，再统计它们的出现频次；若大量 URI 只 MISS 一次就消失，说明长尾被自然跳过 - 关注
proxy_cache_path目录下文件增长速度——优化后，小文件数量应明显下降，inode 消耗趋缓
