开启 proxy_cache 并合理配置可显著降低回源率，关键在于分层缓存策略：静态资源设长TTL（如1年），HTML页用短TTL+revalidate，动态接口原则上不缓存；通过 proxy_cache_min_uses 控制写入门槛，proxy_cache_lock 防击穿，proxy_cache_use_stale 保可用，并借助 $upstream_cache_status 实现可观测。
开启 proxy_cache 并合理配置，能让 Nginx 在反向代理路径上缓存后端响应，使重复请求直接从本地磁盘/内存返回，无需每次打到源站——这是降低回源率最直接、最可控的手段。关键不在“开不开”，而在“缓什么、缓多久、怎么更新、怎么防穿透”。
明确缓存对象：按内容特性分层设置
不同资源更新频率和价值差异大，统一缓存策略会浪费空间或引发一致性问题：
-
静态资源（.js/.css/.png/.webp/.pbf）：更新极少，建议设长 TTL，例如
proxy_cache_valid 200 304 1y;；矢量瓦片可缓存一年，栅格瓦片若依赖样式，则需配合Cache-Control: immutable或版本化 URL 避免误刷新 -
HTML 页面（如首页、列表页）：可用短 TTL + revalidate 组合，例如
proxy_cache_valid 200 304 10m;搭配proxy_cache_revalidate on;，过期后发条件请求验证，命中 304 就复用并刷新 Age -
动态接口（含用户态、实时数据）：原则上不缓存；若需降级兜底，用
proxy_cache_use_stale error timeout http_500;，但必须配合proxy_cache_bypass $arg_nocache $cookie_user_id;显式跳过敏感请求
控制缓存写入门槛：用 proxy\_cache\_min\_uses 过滤低频请求
避免为只访问一两次的 URL 浪费缓存空间和磁盘 IO：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 设
proxy_cache_min_uses 3;表示同一proxy_cache_key至少被请求 3 次，第 3 次响应才写入缓存；前两次仍回源，但不落盘 - 对已知低频路径（如带随机 traceid 的埋点、A/B 实验上报），优先用
map或if跳过整个缓存模块：proxy_cache off;或直接proxy_pass不走 cache 分支 - 注意它只影响“是否写缓存”，不影响“是否读缓存”——已缓存的内容仍正常服务，不会因 min_uses 设置而失效
提升缓存稳定性：防击穿、防雪崩、保可用
高并发下缓存失效易引发源站洪峰，需多层防护：
-
proxy_cache_lock on;：同一 key 的首个未命中请求去回源，其余等待，避免多个并发请求同时穿透 -
proxy_cache_use_stale updating;：当缓存过期正被后台校验时，前台继续返回旧内容，用户无感知 -
proxy_cache_use_stale error timeout http_500;：后端异常时降级返回过期缓存，保障基本可用性 - 搭配
proxy_cache_valid any 1m;可兜底处理未明确声明缓存策略的响应，防止完全不缓存
验证与可观测：用 $upstream\_cache\_status 看清真实行为
在响应头中暴露缓存状态，是调优的基础：
- 加
add_header X-Cache-Status $upstream_cache_status;，响应中可见HIT、MISS、EXPIRED、REVALIDATED、STALE等值 - 日志中记录该变量：
log_format main '$remote_addr - $upstream_cache_status $request $status';，便于统计各状态占比 - 若大量出现
EXPIRED但无REVALIDATED，说明proxy_cache_revalidate未生效或后端未返回 304；若持续MISS，需检查proxy_cache_key是否含变动参数（如时间戳、session id）
