proxy_cache_min_uses需按路径语义分层设置:静态资源设2,首页和公共接口设1,带用户标识路径剔参后设2或3,上报接口用proxy_no_cache绕过;必须精简proxy_cache_key并启用proxy_cache_lock。

直接在对应 location 块里写 proxy_cache_min_uses 2; 就行,但必须配合精简的 proxy_cache_key 和开启 proxy_cache_lock,否则它基本不生效。
按资源类型分层设值
不能全局统一设一个数,要根据路径语义和访问规律来:
-
静态资源(.js/.css/.png/.woff2 等):设为
2。真实用户二次加载概率高,能过滤爬虫、CI 构建、本地调试等单次请求 -
首页(
location = /)和公共接口(如/api/config):保持1。首次访问就该缓存,避免冷启动延迟 -
带用户标识的路径(如
/user/123、/order?id=456):设为2或3,但前提是先剔除token、t等干扰参数,让同一用户的多次请求落在同一个 key 上 -
含随机参数的上报接口(如
/log?r=abc&t=123):不依赖min_uses,直接用proxy_no_cache 1或proxy_cache_bypass $arg_r $arg_t绕过整个缓存流程
cache_key 必须精简,否则 min_uses 形同虚设
如果 key 包含所有查询参数,/logo.png?v=1 和 /logo.png?v=2 就是两个不同 key,永远达不到计数门槛。推荐写法:
安全更新和维护 CLI Proxy API(CPA)部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 静态资源:
proxy_cache_key "$scheme$host$uri";(彻底排除参数) - 带业务参数的 API:
proxy_cache_key "$scheme$host$uri$is_args";(只保留是否有参数,不保留具体值) - 需要保留部分参数时,用
map提前提取稳定字段,再拼进 key
必须搭配 proxy_cache_lock 才防并发刷盘
只设 min_uses 2 不加锁,两个相同请求几乎同时到达,可能都回源、都尝试写缓存,IO 白耗。正确做法:
proxy_cache_lock on;-
proxy_cache_lock_timeout 5s;(略大于后端 P95 响应时间) - 第一个请求回源 + 加锁;后续同 key 请求等待;锁释放时统一写入一次,自然满足“第 2 次”条件
验证是否生效看响应头
用相同请求连续发两次,观察 X-Cache-Status 响应头:
- 第一次:显示
MISS(未达阈值,不落盘) - 第二次:仍显示
MISS(因等待锁,但锁释放后完成写入) - 第三次起:才开始出现
HIT

















