开启 proxy_cache_background_update 须配合 proxy_cache_use_stale updating 等完整配置才生效，否则不仅不降开销反而引发雪崩；需合理设置 cache 有效期、启用 cache lock、收紧后台请求超时与重试策略。

开启 proxy_cache_background_update 本身不会自动降低更新开销，它只在特定条件下“悄悄发起一次后台请求”，真正起效的前提是一整套协同配置——否则不仅开销不降，反而可能因并发失控拖垮后端。

必须启用 proxy_cache_use_stale updating

这是整个机制的启动开关。Nginx 默认遇到过期缓存会阻塞等待回源；只有明确允许“用正在更新的旧内容响应”，才可能跳过等待、释放用户线程、并触发后台子请求。

• 仅写 updating 不够，建议补全常见异常：proxy_cache_use_stale updating error timeout http_500 http_502 http_503 http_504
• 没有这行，background_update 形同虚设：用户收不到旧缓存，后台请求永远不会发出

合理设置 proxy_cache_valid 和 inactive 时长

缓存生命周期决定后台更新的触发频率和持续压力。太短 → 高频刷新；太长 → 内容陈旧，但后台任务少；关键在于匹配业务节奏。

FastAPI Flask Proxy

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

下载

• proxy_cache_valid 200 302 30s：API 类接口推荐 10s～2m，兼顾新鲜度与上游负载
• proxy_cache_valid 404 10s：避免错误路径长期占位，减少无效更新
• proxy_cache_path ... inactive=5m：应显著大于 proxy_cache_valid，确保条目在无访问时才清理，不影响后台更新执行

务必开启 proxy_cache_lock 防止并发击穿

同一缓存 key 过期时，若无锁控制，100 个并发请求会同时触发 100 次后台回源——这不是降开销，而是制造雪崩。

• proxy_cache_lock on：确保只有一个请求穿透缓存去拉新数据
• proxy_cache_lock_timeout 3s：超时后直接走 stale 分支，不卡主响应
• proxy_cache_lock_age 10s：锁释放后 10 秒内禁止重复抢锁，防抖动刷新

后台请求要独立节制，不与主流量争资源

后台更新默认复用主请求的超时、缓冲和重试策略，容易拖慢 worker 或耗尽连接。需单独收紧：

• proxy_connect_timeout 2s; proxy_read_timeout 4s;：比主请求更激进，快速失败
• proxy_next_upstream error timeout http_502 http_503; proxy_next_upstream_tries 2;：最多尝试两次，避免重试风暴
• 必要时用 limit_req 对后台更新路径限流（配合 map 提取 $upstream_cache_status 为 UPDATING 的请求）