关键是要配合 proxy_cache_use_stale updating、proxy_cache_valid 和 proxy_cache_lock 等指令协同工作：必须启用 proxy_cache_use_stale updating 才允许返回过期缓存并触发后台更新，必须设置 proxy_cache_valid 定义过期规则，必须开启 proxy_cache_lock 防止并发回源。
要让 Nginx 在缓存过期后仍快速响应用户，同时悄悄更新内容，关键不是只打开 proxy_cache_background_update on，而是整套配置协同工作。它本身不“自动生效”，必须配合缓存策略、陈旧内容授权和并发控制才能真正实现后台异步更新。
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
必须启用 proxy_cache_use_stale updating
这是最常被忽略却最关键的一环。Nginx 默认遇到过期缓存会阻塞等待回源，除非你明确告诉它：“允许在正在更新时返回旧内容”。
必须写全：
– updating：授权返回正在后台刷新的过期缓存
– 建议补上 error timeout http_500 http_502 http_503 http_504，增强容错能力
例如：proxy_cache_use_stale updating error timeout http_500 http_502 http_503 http_504;
没有 updating，即使开了 background update，用户也收不到旧缓存，后台请求形同虚设。
明确定义缓存有效期（proxy_cache_valid）
没有有效期，Nginx 就无法判断“是否过期”，整个后台更新逻辑就失去触发依据。
– 必须为常见状态码设置合理时长，如：proxy_cache_valid 200 302 10m;
– 对错误响应也建议缓存短时间，防刷或降级：proxy_cache_valid 404 10s;
– 若用于 API，可按业务节奏设更短时间（如 30s～2m），平衡新鲜度与压力。
开启并加固后台更新行为
仅开启 proxy_cache_background_update on 是基础，还需防止它引发新问题：
– 开启 proxy_cache_lock on：确保同一缓存 key 只有一个请求真正回源，其余直接复用旧内容
– 设置 proxy_cache_lock_timeout 5s：避免锁等待太久，超时后立即走 stale 路径
– 可选加 proxy_cache_lock_age 15s：锁释放后 15 秒内禁止重复触发更新，防抖动
– 后台请求本身也要节制：用 proxy_read_timeout 5s 和 proxy_next_upstream_tries 2 防止慢响应拖垮 worker
验证是否生效
上线后靠响应头快速确认：
– 加这行配置便于观察：add_header X-Cache-Status $upstream_cache_status;
– 正常命中新鲜缓存：响应头含 X-Cache-Status: HIT
– 后台更新中且返回旧内容：显示 X-Cache-Status: STALE
– 用 curl 连续请求两次，间隔略超 proxy_cache_valid 时间，第二次应秒回且带 STALE；同时检查上游日志，应只出现一次新请求记录。
