proxy_cache_background_update 不实现异步清理，而是启用后台更新机制：缓存过期后首个请求同步回源更新，其余请求继续使用过期缓存（需 proxy_cache_use_stale updating 配合），Nginx 在后台异步刷新缓存，避免惊群请求。
proxy_cache_background_update 并不实现“异步清理”，而是控制缓存过期后是否启用后台更新机制——即在旧缓存仍可服务的同时，由 Nginx 异步发起上游请求更新缓存内容。它和缓存清理（如 proxy_cache_purge 或 ngx_cache_purge 模块）完全无关。
它解决的核心问题：避免缓存失效时的“惊群请求”
当缓存条目过期，多个并发请求同时到达时，若都去回源拉取新内容，会造成上游压力陡增。启用该指令后：
- 第一个请求发现缓存已过期，会立即回源并更新缓存（同步）
- 其余请求则继续使用已过期但未删除的缓存（需配合
proxy_cache_use_stale updating） - Nginx 在后台悄悄发起一次回源请求，完成缓存刷新，不影响用户响应
必须配合的关键指令才能生效
单独开启 proxy_cache_background_update on 不起作用。需同时配置：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
-
proxy_cache_use_stale updating;：允许在后台更新期间返回过期缓存 - 缓存区域已通过
proxy_cache_path正确定义（含inactive和max_size） - 响应头中应有合理的
Cache-Control或Expires，或通过proxy_cache_valid显式设置缓存时间
它不是缓存清理，也不影响 purge 行为
如果你的目标是“异步清理某类缓存”，例如按前缀批量删除、或延迟清除过期项：
-
proxy_cache_background_update完全不参与此类操作 - 真正的清理需依赖：
proxy_cache_purge（需编译ngx_http_cache_purge_module）、curl -X PURGE接口、或定期用脚本调用rm -f缓存文件（不推荐） - 后台更新只发生在“缓存命中但已过期 + 有请求触发”场景下，不会主动扫描或清理磁盘中闲置缓存
一个典型配置片段
以下配置启用后台更新与过期缓存兜底：
proxy_cache_path /var/cache/nginx/mycache levels=1:2 keys_zone=mycache:10m max_size=1g inactive=60m use_temp_path=off;
server {
location /api/ {
proxy_pass http://backend;
proxy_cache mycache;
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;
add_header X-Cache-Status $upstream_cache_status;
}
}
此时，当缓存过期后首个请求触发回源，后续请求将看到 HIT（因返回的是过期缓存），而 Nginx 在后台静默完成刷新。下次请求即可拿到新鲜内容。
