proxy_cache_background_update 的核心作用是在缓存过期时用旧缓存响应用户请求并后台异步更新，缓解高并发下后端压力；需配合 proxy_cache_use_stale updating 等指令协同生效，且依赖旧缓存未被 inactive 淘汰。
proxy_cache_background_update 的核心作用，是在缓存过期时，让 Nginx 用旧缓存响应用户请求，同时在后台悄悄更新缓存——这正是应对流量激增的关键缓冲机制。
它如何缓解高并发下的后端压力
当大量请求同时命中一个即将过期或已过期的缓存项时，若不启用该指令，Nginx 默认会阻塞所有请求，只让第一个去回源，其余等待；一旦缓存失效窗口大、后端慢，极易引发“缓存雪崩式排队”。而开启 proxy_cache_background_update on 后：
- 首个请求发现缓存过期，立即触发后台更新，同时把旧缓存内容返回给客户端
- 后续请求在后台更新完成前，全部直接读取未过期的旧缓存（只要它还没被主动清理）
- 后台更新成功后，新缓存自动生效，下次请求就拿到最新内容
必须配合的关键配置项
单独开启 background update 并不能发挥效果，需与以下指令协同使用：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- proxy_cache_use_stale updating：明确允许在缓存处于 “updating” 状态时继续使用旧缓存。这是启用 background update 的前提，否则 Nginx 仍会拒绝使用过期缓存
-
proxy_cache_valid：合理设置不同状态码的缓存时间（如
200 302 10m），确保有足够长的“可 stale 使用窗口” -
proxy_cache_lock：建议关闭（
off）或谨慎启用。若开启，background update 期间仍可能对同一 key 加锁，抵消部分并发优势
实际部署中要注意的细节
这个机制不是“万能保险”，使用时需留意：
- 旧缓存必须还存在于磁盘/内存中（未被
proxy_cache_path的inactive时间淘汰）才能被复用 - 后台更新失败不会通知前端，用户始终拿到旧数据，直到下一次成功更新或缓存彻底过期
- 日志中不会单独标记 background update 请求，默认归入常规 access log，可通过自定义 log_format +
$upstream_cache_status区分（如HIT、STALE、UPDATING）
一个典型配置片段参考
用于静态资源或 API 结果缓存，兼顾一致性与吞吐：
proxy_cache_path /var/cache/nginx/api_cache levels=1:2 keys_zone=api_cache:10m inactive=5m max_size=1g;
server {
location /api/ {
proxy_cache api_cache;
proxy_cache_valid 200 302 30s;
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
proxy_cache_background_update on;
proxy_cache_lock off;
proxy_pass https://backend;
}
}
这里将有效缓存设为 30 秒，但允许在更新中继续提供最多 5 分钟内未被访问的旧缓存，既防突发流量打垮后端，又避免数据长期陈旧。
