要实现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 日志：同一资源在过期后，应只出现一次新请求记录，而非每次请求都打过去