proxy_cache_background_update 的作用是让 Nginx 在缓存过期后立即返回旧内容并后台静默更新，而非主动异步刷新；它依赖 proxy_cache_use_stale updating 等配合，在请求命中 stale 缓存时触发单次后台回源，保证响应速度与缓存一致性平衡。

proxy_cache_background_update 的作用不是“实现异步更新”，而是让 Nginx 在缓存过期后，仍可立即返回旧缓存内容，同时在后台悄悄拉取新内容并更新缓存——它本身不触发更新，也不控制更新逻辑，只是改变缓存过期时的响应行为。

它如何工作：过期即用 + 后台刷新

启用该指令后，当请求命中一个已过期（stale）但尚未被主动刷新的缓存项时：

• Nginx 立即返回当前缓存内容（哪怕已过期），避免用户等待回源
• 同时，在后台发起一次与原始请求几乎相同的子请求（subrequest）到上游，获取新响应
• 若新响应有效（状态码 200/304 等、且满足 cache 条件），就用它原子性地替换旧缓存
• 整个过程对客户端完全透明，用户无感知

必须配合的关键配置

单独开启 proxy_cache_background_update on 是无效的，需同时满足：

CPA Update - Secure CLI Proxy API Maintenance

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

下载

• proxy_cache_use_stale updating：允许在缓存正在 background 更新时，继续使用旧缓存（这是“过期即用”的前提）
• proxy_cache_valid 设置了缓存有效期（如 200 302 10m）
• proxy_cache_lock off（推荐）：避免 background update 被 cache lock 阻塞；若开启 lock，background update 会被排队，失去“后台”意义
• 上游响应需带明确的 Cache-Control 或 Expires，或由 proxy_cache_valid 显式定义过期时间

实际效果示例

假设缓存有效期为 60 秒，用户 A 在 t=65s 发起请求：

• 缓存已过期 → 若未启用 updating，Nginx 会阻塞等待回源，用户等待
• 启用 use_stale updating + background_update on → 立即返回 t=0~60s 缓存的内容，同时后台静默请求上游
• 用户 B 在 t=66s 请求同一资源 → 仍可能拿到旧缓存（除非后台更新已完成），同样不等待
• 后台更新成功后，后续请求才开始拿到新内容

它不是“定时刷新”，也不保证强一致

注意几个常见误解：

• 它不主动轮询或定时触发更新，只在有请求命中 stale 缓存时才触发后台 fetch
• 没有请求，就不会更新缓存（冷数据不会自动刷新）
• 多个并发请求命中同一 stale 缓存时，Nginx 默认只发起一次 background update（内部去重），不是每个请求都回源
• 更新失败（如上游超时、返回 5xx）不会影响已返回的 stale 内容，也不会报错，旧缓存继续保留

它解决的是“缓存过期瞬间的性能毛刺”，本质是用短暂的陈旧性换响应速度，而非实现传统意义的异步任务调度。