proxy_cache_background_update真正生效需配齐四环节：启用proxy_cache_use_stale updating作为启动开关，设置proxy_cache_valid定义有效期，开启proxy_cache_lock防并发击穿，确保proxy_cache_key与keys_zone严格匹配。

要让 proxy_cache_background_update 真正生效，不是单独打开它就行，而是必须配齐四个关键环节：授权返回过期内容、定义缓存有效期、防止并发回源、确保缓存基础一致。

必须启用 proxy_cache_use_stale updating

这是整个机制的启动开关。Nginx 默认遇到过期缓存会阻塞等待回源；只有明确写上 updating，它才敢把旧内容立刻返回，并顺手发起后台刷新。

• 只写 updating 不够健壮，建议补全常见容错项：
  proxy_cache_use_stale updating error timeout http_500 http_502 http_503 http_504;
• 漏掉 updating，后台更新永远不会触发，哪怕其他配置全对

必须设置明确的 proxy_cache_valid 规则

没有有效期，就没有“过期”，也就谈不上“过期后后台更新”。Nginx 靠它判断何时进入 stale 阶段。

CPA Update - Secure CLI Proxy API Maintenance

安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。

下载

• 为常用状态码设有效期，例如：
  proxy_cache_valid 200 302 10s;（API 类推荐 10s～2m）
• 单独控制 404：
  proxy_cache_valid 404 1s;，避免无效响应长期占位
• 带哈希的静态资源（如 app.a1b2c3.js）可设更长，如 1h

必须开启 proxy_cache_lock 防击穿

多个请求同时命中同一过期 key，若不加锁，可能瞬间触发几十次后台回源，压垮上游服务。

• proxy_cache_lock on; —— 只允许一个请求真正回源
• proxy_cache_lock_timeout 5s; —— 抢不到锁就直接走 stale，不卡主响应
• 可选加固：proxy_cache_lock_age 15s;，刚刷完的缓存 15 秒内禁止重复更新

必须保障 cache_key 和 keys_zone 严格匹配

后台子请求要能复用原有缓存项，依赖 key 计算方式和存储区域完全一致。

• proxy_cache_path 中的 keys_zone 名称（如 mycache）必须与 location 中 proxy_cache mycache; 完全一致
• proxy_cache_key 推荐用：
  $scheme$host$request_uri$is_args$args
• 避免混入易变字段：如未过滤的 $cookie_session、$time_iso8601、随机参数等
• 确认后端能接受无认证的后台子请求（不带敏感 header 或 session）