要让proxy_cache_background_update真正生效，必须协同配置：①启用proxy_cache_use_stale updating授权返回过期缓存；②明确定义proxy_cache_valid有效期；③开启proxy_cache_lock防并发回源；④确保proxy_cache_path与proxy_cache_key稳定。
要让 proxy_cache_background_update 真正激活后台异步更新、降低首包响应延迟，关键不是单独打开这个指令，而是构建一套协同生效的缓存容灾链路。它本身不触发任何动作，只在“缓存已过期但被允许返回”时，才悄悄发起后台子请求——所以必须先让 Nginx 有底气用旧内容响应。
必须启用 proxy_cache_use_stale updating
这是整个机制的启动钥匙。Nginx 默认遇到过期缓存会阻塞等待回源，只有显式授权它“允许在更新中返回旧内容”，后续逻辑才能流转：
- 必须写全：
proxy_cache_use_stale updating error timeout http_500 http_502 http_503 http_504 - 仅写
updating不够健壮；加上错误类参数，可覆盖回源失败时的兜底场景 - 没有这行，即使开了
background_update，用户也收不到旧缓存，后台请求永远不会启动
必须明确定义 proxy_cache_valid 过期规则
没有有效期，就没有“过期”概念，也就谈不上“过期后返回 stale + 后台更新”：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 例如：
proxy_cache_valid 200 302 30s;表示 200/302 响应缓存 30 秒 - 对 API 类接口，建议设为 10s～2m，平衡新鲜度与压力
- 对带哈希的静态资源（如
app.abc123.js），可设为 1h 或更长，因文件名变即内容变 - 务必为 404 单独设置短有效期，如
proxy_cache_valid 404 10s，避免无效条目长期占位
必须开启 proxy_cache_lock 防止并发击穿
多个请求同时命中同一过期 key，若不加锁，可能瞬间触发几十个后台回源，反而加重上游负担：
-
proxy_cache_lock on;：确保同一 cache key 只有一个请求真正回源 -
proxy_cache_lock_timeout 5s;：锁等待超时后，直接走 stale 路径返回旧内容，不卡主响应 - 可选加
proxy_cache_lock_age 15s：锁释放后 15 秒内禁止新更新，防抖动
必须确保缓存区和 cache_key 稳定可用
后台子请求能否成功更新缓存，取决于它是否能复用原有缓存项的 key 和存储位置：
- 全局
proxy_cache_path必须正确定义，且keys_zone名称需与 location 中proxy_cache严格一致 -
proxy_cache_key应保持稳定，推荐使用：$scheme$host$request_uri$is_args$args - 避免在 key 中混入易变字段（如时间戳、随机数、未过滤的 cookie）
- 确保后端支持无认证子请求（后台更新不携带原始请求中的敏感头或 body）
