proxy_cache_background_update 的作用是在缓存即将过期时，不阻塞用户请求，一边返回旧缓存一边后台更新；需配合 proxy_cache_valid、proxy_cache_use_stale updating 和 proxy_cache_background_update on 同时启用。

proxy_cache_background_update 的作用不是“刷新缓存”，而是让 Nginx 在缓存即将过期时，**不阻塞用户请求**，一边把旧缓存返回给客户端，一边在后台悄悄去后端拉取新响应并更新缓存。它解决的是“缓存失效瞬间大量请求穿透到后端”的问题（即缓存雪崩/缓存击穿），而不是主动轮询或定时刷新。

启用 background update 的前提条件

这个功能不会自动生效，必须配合以下配置共同使用：

FastAPI Flask Proxy

FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。

下载

• proxy_cache_valid 必须设置明确的缓存有效期（例如 proxy_cache_valid 200 5m;）
• proxy_cache_use_stale 必须启用至少一项“可接受过期缓存”的指令，比如 updating（关键！没有它，background update 不会触发）
• proxy_cache_background_update on; 显式开启（默认是 off）

典型配置示例

以下是最小可行配置片段（放在 location 块中）：

proxy_cache my_cache;
proxy_cache_valid 200 5m;
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
proxy_cache_background_update on;
proxy_cache_lock on;  # 推荐搭配，避免重复回源

说明：
- 当一个请求命中缓存，且该缓存已存在 4m50s（即距离过期只剩 10s），Nginx 就会认为它“即将过期”；
- 如果此时有新请求进来，且缓存尚未完全过期，Nginx 会立即返回当前旧缓存（因为 updating 在 proxy_cache_use_stale 中）；
- 同时，Nginx 在后台发起一个异步子请求到后端，获取新响应，并用它更新缓存——整个过程对用户透明、无延迟。

它不做什么？常见误解澄清

• 不是定时刷新：它只在有请求触发、且缓存临近过期时才后台回源，没有请求就不会动作
• 不保证强一致性：用户可能在更新完成前持续拿到旧内容（这是设计目标：可用性优先）
• 不替代 purge 或主动失效机制：后端数据变更时，仍需通过 proxy_cache_purge 或时间戳/版本号等手段主动清理缓存
• 不降低首次回源延迟：第一次访问或缓存彻底过期后首次访问，仍会同步阻塞等待后端响应

验证是否生效的方法

可通过日志和缓存状态辅助判断：

• 开启 log_format 记录 $upstream_cache_status，看到 UPDATING 状态表示后台更新已触发
• 用 curl -I 观察响应头中的 X-Cache（若自定义）或 Age 头变化趋势
• 在后端加简单日志，观察在高并发下，同一资源的请求是否明显减少（说明多数被缓存 + background update 拦截）