Nginx 用 proxy_cache_use_stale 应对源站抖动，核心是缓存命中前提下复用已缓存的正常或错误响应；需精准启用 http_500/502/503/504，稳定 cache_key，缓存错误码，验证 STALE 响应头与内容一致性。
直接用 proxy_cache_use_stale 应对源站抖动，关键不是“兜底”，而是让 Nginx 在短暂异常期间继续吐出已有的缓存内容——前提是缓存本身稳定、可命中、且错误响应也被收进去了。
只启用抖动场景真正需要的触发条件
源站抖动通常表现为偶发 502/503/504 或短时超时，而非彻底宕机。应精准配置，避免误放大问题：
- 明确写
proxy_cache_use_stale http_500 http_502 http_503 http_504;—— 这些是后端主动返回的明确故障信号，可信度高 - 不加
error或timeout：网络瞬断、DNS 波动或单次读超时可能被误判，导致本可成功的请求也走 stale，反而降低可用性 - 如需后台静默刷新，可加
updating，但必须同步开启proxy_cache_background_update on;
确保缓存链路对静态资源真正有效
stale 生效的前提是：有缓存、能命中、过期了还能用。静态资源容易因配置疏漏导致缓存失效：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
-
proxy_cache_key必须稳定：推荐用$scheme$host$request_uri，去掉所有动态参数（如?v=123、&utm_source=xxx），否则相同文件每次请求都算新 key -
proxy_cache_valid要覆盖常见状态码：至少包含proxy_cache_valid 200 301 302 1h;和proxy_cache_valid 500 502 503 504 5m;—— 错误响应也进缓存，后续抖动时才能复用 - 确认
proxy_cache_path已定义且磁盘空间充足，proxy_cache在 location 中正确引用对应 zone
验证抖动下是否真返回旧内容，而非报错或空响应
别只看状态码是 200 就认为成功。要从客户端视角确认三件事：
- 响应头中出现
X-Cache: STALE（需提前配add_header X-Cache $upstream_cache_status;） - 响应体与抖动前完全一致：比如一张 PNG 图片的二进制内容、一个 CSS 文件的文本内容，不能变成 Nginx 默认 502 页面
- 响应耗时极低（例如 proxy_read_timeout（如设为 3s），说明确实跳过了回源
搭配后台更新，让用户无感过渡到新内容
单纯返回陈旧资源只是第一步。更优做法是：返回旧内容的同时，悄悄拉新：
- 开启
proxy_cache_background_update on;：stale 响应发出后，Nginx 自动在后台发起新请求更新缓存 - 启用
proxy_cache_lock on;和proxy_cache_lock_timeout 3s;：防止多个并发请求同时发现缓存过期，集体击穿源站 - 对关键静态资源（如首页 JS/CSS），可结合短 TTL（如
proxy_cache_valid 200 5m;）+ background update，平衡新鲜度与稳定性
