要让 proxy_cache_background_update 支撑高可用，必须构建容错闭环：启用 proxy_cache_use_stale updating error timeout http_500–504，分层设置 cache 有效期与 stale 窗口，配合 proxy_cache_lock 防击穿，并为后台请求配置独立超时与重试。
要让 proxy_cache_background_update 在真实生产中支撑高可用，关键不是打开这个开关，而是构建一套容错闭环：它只在“缓存已过期但被允许返回旧内容”时才悄悄发起后台刷新。没有容错兜底，它就形同虚设。
必须启用 proxy_cache_use_stale updating 并覆盖常见故障
这是整个机制的启动前提。Nginx 默认遇到过期缓存会阻塞等待回源；只有明确授权它“可用旧内容响应”，后台更新才有触发机会：
- 必须写全：
proxy_cache_use_stale updating error timeout http_500 http_502 http_503 http_504；仅写updating无法应对上游宕机、超时等真实故障 - 若后端返回 502 或连接超时，该配置能让 Nginx 立即返回 stale 缓存，并同步触发 background update
- 不配这一项，即使开了
background_update，用户也会卡住等待，后台请求根本不会发出
缓存有效期需分层设定，明确 stale 窗口
单靠 proxy_cache_valid 200 302 10s 不够——它只定义“新鲜期”。高可用要求你额外划出一段“可容忍陈旧”的时间窗口：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 推荐组合：
proxy_cache_valid 200 302 10s; proxy_cache_valid 200 302 2m;，表示 10 秒内直接 HIT，10 秒后进入 stale 阶段，最多再撑 2 分钟 - 对静态资源（如 JS/CSS），可设
proxy_cache_valid 200 1h; proxy_cache_valid 404 5m;，避免无效 404 占满缓存空间 - 对 API 接口，建议基础有效期设为 5–30 秒，stale 窗口设为 1–2 分钟，兼顾一致性与抗压能力
必须搭配 proxy_cache_lock 防止并发击穿
background_update 本身不防并发。1000 个请求同时命中同一过期 key，若无锁控制，就会瞬间发 1000 次后台回源，反而压垮上游：
-
proxy_cache_lock on;确保同一 cache key 只有一个请求真正回源 -
proxy_cache_lock_timeout 2s;超时后放弃抢锁，直接走 stale 返回，不卡主响应 -
proxy_cache_lock_age 10s;锁释放后 10 秒内禁止新锁竞争，防止刚刷完又被刷，减少抖动
后台子请求需独立限流与快速失败
后台更新虽不阻塞用户，但默认共享主请求的超时和缓冲配置，容易拖慢整体调度或耗尽 worker 连接：
-
proxy_connect_timeout 3s; proxy_read_timeout 5s;—— 比主请求更激进，确保后台请求快速失败 -
proxy_next_upstream error timeout http_500 http_502 http_503 http_504;+proxy_next_upstream_tries 2;+proxy_next_upstream_timeout 6s;，两次尝试内必须结束，否则丢弃 - 确保后端能接受无认证、无敏感头的子请求（后台更新不携带原始 Cookie 或 Authorization）
