proxy_cache_min_uses 是 Nginx 控制缓存冷启动的参数，定义相同 URI 需被访问指定次数后才写入缓存，默认为 1；它决定“何时缓存”而非“是否缓存”，仅影响写入，需与 proxy_cache_valid、proxy_cache_key 等协同生效。

proxy_cache_min_uses 是 Nginx 反向代理中控制缓存“冷启动”的关键参数，它定义了请求需被访问多少次后，响应才被正式写入缓存。默认值为 1，即首次请求就缓存；设为 2 或更高，则需相同 URI 被重复请求达到指定次数，Nginx 才会将响应存入 cache。这能有效避免一次性或试探性请求污染缓存空间。

理解 proxy_cache_min_uses 的作用逻辑

该指令不决定“是否缓存”，而是决定“何时开始缓存”。它和 proxy_cache_valid、proxy_cache_key 协同工作：只有满足最小访问次数 + 响应状态码匹配 + 缓存键一致，才会触发写缓存动作。注意：它只影响缓存写入（store），不影响缓存读取（hit/miss）。

• 设为 1：每次成功响应（符合 proxy_cache_valid）都立即缓存
• 设为 3：同一 URI 必须被相同 cache key 的请求命中 3 次（且前两次未缓存），第 3 次响应才写入缓存
• 对动态接口或低频页面，调高此值可显著降低无效缓存占比

在 location 块中正确配置示例

必须配合启用的缓存区（proxy_cache）使用，且建议与 proxy_cache_use_stale、proxy_cache_lock 等协同优化体验：

FastAPI Flask Proxy

FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。

下载

proxy_cache my_cache;
proxy_cache_min_uses 2;
proxy_cache_valid 200 302 10m;
proxy_cache_valid 404 1m;
proxy_cache_key "$scheme$request_method$host$request_uri";

⚠️ 注意：若使用了 proxy_cache_bypass 或 proxy_no_cache，它们的判断优先级高于 min_uses —— 返回 true 时直接跳过缓存流程，无论访问次数多少。

常见误用与排查要点

当设置 proxy_cache_min_uses > 1 却始终不缓存，需检查以下几项：

• 是否所有请求的 proxy_cache_key 完全一致？Cookie、时间戳、随机参数会导致 key 不同，计数无法累积
• 响应状态码是否落在 proxy_cache_valid 覆盖范围内？如返回 500，默认不缓存
• Nginx 版本是否 ≥ 1.7.0？该指令自该版本起支持，旧版无效
• 是否启用了 proxy_buffering off？关闭缓冲可能干扰缓存写入流程

结合业务场景调整建议

没有绝对最优值，应根据流量特征和资源特性权衡：

• 静态资源（JS/CSS/图片）：保持默认 1 即可，高频且稳定
• 用户中心页（含 Cookie）：建议设为 2–3，并精简 cache_key（如剔除 session_id）
• 搜索结果页（带分页/关键词）：设为 3–5，避免大量长尾 query 占用 cache 空间
• 监控类 API（每分钟轮询）：可设为 1，但用 proxy_cache_valid 限制极短有效期（如 1s）