配置 proxy_cache_use_stale updating 的核心目标是缓存过期时立即返回旧内容并后台更新，需配合 proxy_cache_background_update on、分层 proxy_cache_valid 和 proxy_cache_lock 才生效。
配置 proxy_cache_use_stale updating 的核心目标，是让 Nginx 在缓存已过期时，不阻塞用户请求，而是立即返回旧内容，同时在后台悄悄拉取新响应更新缓存。它不是“自动刷新开关”，而是一个“允许发旧数据”的授权指令——必须和其他三要素配合才真正生效。
必须同步开启 background_update
updating 参数本身不会发起任何后台请求。它只起判断作用：当缓存过期后，Nginx 查到当前有其他请求正在刷新该 key（由 proxy_cache_lock 触发），且你写了 updating，才允许把已过期的缓存直接返回给新请求。
- 必须显式启用：
proxy_cache_background_update on; - 若未开启，即使写了
updating，Nginx 仍会阻塞等待回源完成，失去“无感过渡”意义 - 后台子请求使用低优先级，不影响主响应耗时，失败也不报错、不中断服务
缓存有效期要分层设置
只写一行 proxy_cache_valid 200 5m; 不够。Nginx 需要明确知道“什么时候算新鲜”、“什么时候算可容忍陈旧”：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 定义基础新鲜期：
proxy_cache_valid 200 302 10s;（比如 10 秒内视为完全新鲜） - 再定义宽限期：
proxy_cache_valid 200 302 1m;（1 分钟内允许 stale，含 updating 场景） - 两者共存时，Nginx 以更长的有效期为准做缓存存储，但用更短的值判断是否进入 stale 流程
必须搭配 cache_lock 才能触发 updating
updating 的前提是“有请求正在更新缓存”。这个“正在更新”状态，由 proxy_cache_lock 机制产生：
- 开启锁：
proxy_cache_lock on; - 设合理超时：
proxy_cache_lock_timeout 2s;（超时后不再等，直接走 stale 或 background update） - 设锁老化时间：
proxy_cache_lock_age 15s;（防止刚刷完又被立刻抢锁重刷） - 没有 lock，就不会有“正在更新”的上下文，updating 就永远不被激活
验证是否真在按预期工作
上线后别只看配置，用实际行为确认：
- 加头暴露状态：
add_header X-Cache $upstream_cache_status;，请求返回X-Cache: STALE表示命中并触发了 updating - 停掉后端后连续 curl 两次，间隔略超新鲜期（如设了 10s，等 12s 再发第二请求），应秒回且带 STALE 头
- 查缓存目录中对应 key 文件的修改时间，持续变化说明 background update 正在运行
