如何通过 proxy_cache_background_update 实现过期缓存资源的后台静默刷新-Nginx-PHP中文网

proxy_cache_background_update的核心作用是缓存过期时立即返回旧内容并后台异步刷新，避免阻塞响应和并发回源；需配合proxy_cache_use_stale updating、proxy_cache_valid、proxy_cache_lock等配置协同生效。

如何通过 proxy_cache_background_update 实现过期缓存资源的后台静默刷新

proxy_cache_background_update 的核心作用是：当缓存资源已过期（但尚未被删除），客户端发起请求时，Nginx 不立即回源拉取新内容并阻塞响应，而是**立刻返回当前过期的缓存副本**，同时在后台异步发起回源请求，更新缓存。这既保证了响应速度，又避免了“缓存雪崩”式的并发回源。

启用后台静默刷新的前提条件

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

必须启用 proxy_cache_use_stale：指定在哪些异常情况下可返回陈旧缓存（如 updating 是关键值）；
必须设置 proxy_cache_valid：明确定义资源的缓存有效期（如 200 302 10m）；
proxy_cache_background_update 需设为 on：显式开启后台更新机制；
建议配合 proxy_cache_lock on：防止同一 key 的多个并发请求同时触发回源（虽 background update 本身不阻塞，但 lock 能减少冗余回源）。

典型配置示例（关键片段）

以下是最小可行配置，部署在 location 块中：

FastAPI Flask Proxy

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

下载

proxy_cache my_cache;
proxy_cache_valid 200 302 10m;
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
proxy_cache_background_update on;
proxy_cache_lock on;
proxy_cache_lock_timeout 5s;

说明：
– 当缓存过期后收到新请求，Nginx 检查到 updating 状态可用（由 proxy_cache_use_stale 启用），就直接返回旧内容；
– 同时启动一个后台子请求去上游拉取最新资源，并写入缓存；
– 下一个请求将命中更新后的缓存（或继续触发后台更新，取决于是否又过期）。

如何验证它是否生效

可通过日志和行为观察确认：

开启 error_log /path/to/error.log notice;，在日志中搜索 cache lock、cache miss、cache stale 等关键词；
用 curl 多次请求同一资源，配合 -H "Cache-Control: no-cache" 绕过浏览器缓存，观察响应头中的 X-Cache（需自定义添加）或响应时间变化；
在 upstream 服务加日志或延迟（如 sleep 2s），首次过期请求应快速返回（旧缓存），几秒后再次请求应返回新内容，且中间只触发一次回源。

常见误区与注意事项

该机制有明确边界，不能替代完整缓存策略：

它只对“已存在但过期”的缓存生效；首次请求或缓存被清除后，仍是常规回源（除非配了 proxy_cache_use_stale bypass 等兜底）；
后台更新失败（如上游超时）不会重试，也不会影响后续请求——下次请求仍会触发新一轮后台更新；
不适用于需要强一致性的场景（如支付结果页），因用户可能看到过期数据；
若上游响应头含 Cache-Control: no-store 或 Set-Cookie，默认不缓存，需用 proxy_ignore_headers 显式忽略才可能进入缓存流程。