proxy_cache_background_update on本身不实现静默刷新，必须与proxy_cache_valid、proxy_cache_use_stale updating、proxy_cache_lock on协同生效：前者定义过期时间，后者授权返回陈旧内容并限制并发回源，缺一不可。
开启 proxy_cache_background_update on 本身不会自动实现“静默刷新”，它只是让 Nginx 在缓存过期后返回旧内容的同时，悄悄发起一次后台回源。真正决定是否刷新、刷几次、谁来刷的，是它和另外几个指令的配合方式。
必须配齐的四个核心配置
缺一不可，否则要么不触发后台更新，要么引发大量并发回源：
-
proxy_cache_valid：明确定义缓存有效期，例如
proxy_cache_valid 200 302 5m。没有它，Nginx 就不知道“什么时候算过期”； -
proxy_cache_use_stale updating：这是关键授权项。只有加上
updating，Nginx 才允许把已过期但尚未更新完成的缓存内容返回给用户（状态为STALE）； - proxy_cache_background_update on：启用后台异步刷新能力，让更新动作不阻塞主响应；
- proxy_cache_lock on：防止多个请求同时触发后台刷新。它确保同一缓存 key 下，只有一个请求真正去上游拉新数据，其余请求直接复用当前缓存（哪怕已过期）。
为什么只开 background_update 很危险
单独启用 proxy_cache_background_update on 后，如果 100 个并发请求同时命中一个刚过期的缓存 key，Nginx 默认会为每个请求都发起一次后台更新——不是 1 次，而是 100 次。这等于把缓存层的保护完全绕开，上游服务瞬间收到百倍压力。日志里会看到大量重复的 MISS 或 UPDATING 记录，CPU 和连接数飙升。
推荐的最小安全配置片段
放在 location 块中即可生效：
proxy_cache my_cache; proxy_cache_valid 200 302 5m; proxy_cache_valid 404 1m; 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 3s;
说明：
-
proxy_cache_lock_timeout 3s表示最多等待锁 3 秒，超时后直接走stale内容，避免用户卡顿； -
404也缓存 1 秒，可防恶意探测或瞬时刷量； - 所有
updating相关行为，都依赖proxy_cache_use_stale中显式包含该关键词。
如何确认它在正常工作
加一行响应头便于观察：
add_header X-Cache-Status $upstream_cache_status;
用 curl 测试时关注三点：
- 首次过期请求返回
X-Cache-Status: STALE，且响应极快（毫秒级）； - 停掉上游服务后，仍能快速返回旧内容（说明
updating授权生效）； - 后台更新完成后，下一次请求变为
HIT，且中间只出现一次回源日志。
不复杂但容易忽略。
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
