要实现Nginx返回旧缓存并后台更新，必须同时配置proxy_cache_use_stale updating、proxy_cache_background_update on、proxy_cache_valid定义新鲜期与宽限期，并启用proxy_cache_lock防并发回源。
要让 Nginx 在返回旧缓存的同时后台悄悄更新，关键不是只写 proxy_cache_use_stale updating，而是把它作为“授权开关”嵌入整套缓存协同机制中——它本身不发起更新，只决定“能不能用过期内容响应用户”。没有它，后续所有静默逻辑都失效。
必须搭配 background update 和缓存有效期
updating 参数只有在缓存已过期、且 proxy_cache_background_update on 开启时才起作用。Nginx 先靠 proxy_cache_valid 判断“是否过期”，再靠 proxy_cache_use_stale updating 决定“过期了敢不敢发”。两者缺一不可：
- 不设
proxy_cache_valid，Nginx 不知道什么是“过期”，updating就无从触发 - 不开
proxy_cache_background_update on，即使允许返回旧内容，也不会启动后台拉新动作 - 推荐组合写法：
proxy_cache_valid 200 302 10s;+proxy_cache_valid 200 302 1m;，前者定义“新鲜期”，后者定义“stale 宽限期”
updating 必须显式写出，不能省略
很多人误以为 proxy_cache_use_stale error timeout 就够了，其实 updating 是独立且强制的参数。只要没写它，哪怕缓存正在后台刷新，Nginx 也会拒绝返回旧内容，转而阻塞等待回源。
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 正确写法：
proxy_cache_use_stale updating error timeout http_500 http_502 http_503 http_504; - 错误写法：
proxy_cache_use_stale error timeout;—— 这样不会触发任何后台更新流程 - 如果上游偶发失败，
updating还能兜底：后台刷新失败时，后续请求仍可走 stale 分支，避免雪崩
需配合 lock 防止并发刷爆后端
updating 只管“能不能发旧数据”，不管“谁来刷新数据”。若大量请求同时击中同一过期 key，没有锁控制，就会瞬间发起数百次后台请求。
- 必须加
proxy_cache_lock on;，确保只有一个请求真正回源 - 设
proxy_cache_lock_timeout 2s;，超时立即走 stale，不卡用户 - 加
proxy_cache_lock_age 15s;，防止刚刷完又被抢锁重刷
验证是否真正生效
上线后别只看配置，用实际行为确认：
- 加响应头：
add_header X-Cache-Status $upstream_cache_status;，看到STALE表示命中旧缓存并已触发后台更新 - 用
curl连续请求两次，间隔略超proxy_cache_valid设置（如设了 10s 就等 12s），第二次应秒回且带STALE - 查 upstream 日志：同一资源在过期后，应只出现一次新请求记录，而非每次请求都打过去
