proxy_cache_background_update 的核心作用是缓存过期后立即返回旧内容并后台静默更新：需配合 proxy_cache、proxy_cache_valid、proxy_cache_background_update on 及稳定 cache_key 使用；命中 stale 时零延迟响应，仅首请求触发后台回源，其余复用 stale；建议搭配 proxy_cache_use_stale updating 等提升容错。

proxy_cache_background_update 的核心作用是：当缓存过期后，Nginx 仍可立即返回旧缓存内容给用户，同时在后台悄悄发起新请求回源拉取最新资源——整个过程对客户端完全透明，无感知延迟或错误。

开启静默刷新的前提条件

该功能不是独立开关，必须与以下配置协同生效：

• 启用缓存：必须配置 proxy_cache 并指定有效的缓存区（如 proxy_cache my_cache）
• 定义过期策略：通过 proxy_cache_valid 明确设置状态码对应的有效时间（例如 proxy_cache_valid 200 302 10m）
• 启用后台更新：显式设置 proxy_cache_background_update on
• 确保缓存键稳定：使用一致的 proxy_cache_key，避免因 key 变化导致后台请求无法命中已有缓存项

关键行为逻辑说明

当一个请求到达时，若对应缓存已过期但尚未被删除（即处于“stale”状态），Nginx 会：

Nginx Reverse Proxy

配置 Nginx 反向代理，实现域名绑定。用户说“绑定域名”“配置 Nginx”“反向代理”时触发，将域名绑定到指定 IP:端口。

下载

• 立刻将当前 stale 缓存体返回给客户端（零延迟响应）
• 在后台用相同请求参数（method、headers、body 等）向 upstream 发起新请求
• 新响应成功后，自动替换旧缓存；失败则保留 stale 内容，等待下次触发
• 同一 stale key 的多个并发请求中，仅首个会触发后台更新，其余继续返回 stale 内容（防击穿）

配合 proxy_cache_use_stale 提升容错能力

单独靠 background update 还不够健壮，建议搭配 proxy_cache_use_stale 应对回源异常：

• proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
• 当后台更新失败（如上游超时或返回 5xx），后续请求仍可返回 stale 缓存，避免雪崩
• 其中 updating 是重点——它专门允许在 background update 执行中直接返回 stale，是静默刷新的兜底保障

验证是否生效的小技巧

可通过日志和响应头辅助判断：

• 开启 log_format 记录 $upstream_cache_status，看到 STALE 表示命中过期缓存并触发后台更新
• 响应头中若出现 X-Cache: HIT-STALE（需自定义 header）或类似标识，说明走的是 stale + background flow
• 观察 upstream 访问日志：同一资源在缓存过期后，应出现“一次后台请求 + 多次客户端响应”，而非每次请求都打到后端

注意：background update 不改变缓存生命周期本身，它只是让“过期后仍可用 + 自动续期”成为可能。真正决定何时过期的，仍是 proxy_cache_valid 和响应头中的 Cache-Control/Expires。