proxy_cache_background_update 用于在缓存过期后返回旧内容的同时后台异步更新，需配合 proxy_cache_use_stale updating 才生效，不主动预热、不改变过期时间，仅在有请求触发 stale 缓存时启动更新。

proxy_cache_background_update 用于控制 Nginx 在缓存过期后，是否在返回旧缓存内容的同时，后台异步重新拉取并更新缓存。它不改变缓存命中或过期判断逻辑，只影响“过期后如何响应客户端 + 如何刷新缓存”的行为。

开启后的行为特点

当该指令设为 on，且请求命中一个已过期（stale）但仍在 proxy_cache_use_stale 允许范围内的缓存时：

• Nginx 立即返回当前缓存内容（避免回源延迟），同时在后台发起一次新的上游请求
• 新响应成功后，会原子性地替换旧缓存，后续请求即可命中新鲜内容
• 若后台更新失败（如上游超时、5xx），原有 stale 缓存仍可继续被使用（前提是 proxy_cache_use_stale 启用了对应条件）
• 该机制对客户端完全透明，无额外头信息或状态变化

依赖前提不能少

该功能不会自动生效，必须配合以下配置：

aperture: the L402 aware reverse proxy

安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。

下载

• proxy_cache_use_stale updating; —— 明确允许在缓存处于 “updating” 状态（即后台正在刷新）时返回 stale 内容
• 缓存本身需已启用（proxy_cache + proxy_cache_valid 等）
• 建议搭配 proxy_cache_lock on; 避免重复更新（同一 key 的多个并发 stale 请求，只放行一个去回源）

典型适用场景

适合对响应延迟敏感、且能接受短暂 stale 数据的业务：

• 高流量静态资源（如 JS/CSS/图片）的缓存刷新，避免大量用户同时触发回源压垮上游
• API 接口缓存，例如商品详情页，允许几秒内显示稍旧数据，但后台静默更新保障后续请求即时生效
• 与 proxy_cache_valid 200 302 10m; 和 proxy_cache_use_stale error timeout updating http_500; 组合，构建更健壮的缓存容错策略

注意点和常见误区

这个指令容易被误解为“主动预热”或“定时刷新”，实际并非如此：

• 它只在有真实请求触发 stale 缓存时才启动后台更新，没有请求就不会刷
• 它不延长缓存有效期，也不改变 proxy_cache_valid 定义的过期时间
• 若未配置 proxy_cache_use_stale updating，即使开启 background update，Nginx 也不会返回 stale 内容，而是直接回源（此时该指令无效）
• 后台更新过程不阻塞主线程，但会占用一个 worker 连接和上游连接，需关注 upstream 连接池压力