proxy_cache_use_stale error http_502 http_503 http_504 实现托底，需配合 proxy_cache_valid 502 503 504 1m 缓存错误响应，并确保缓存区域启用、key 稳定、inactive 足够长，验证时应见 X-Cache: STALE 且返回旧内容。
当使用 proxy_cache_use_stale 实现“更新时出错自动托底”，核心不是让它“处理 error”，而是让它在明确的 error 场景下，**允许返回已存在的过期缓存内容**——前提是这个 error 真实发生，且缓存本身可用、可命中、可复用。
只对可信的 error 类型启用托底
network-level 的 error（如连接被拒、连接重置、上游无响应）是源站彻底宕机的强信号，适合用于托底。但需注意：
- 写法必须是
proxy_cache_use_stale error http_502 http_503 http_504;—— 明确列出你信任的失败类型 - 不要混入
timeout或invalid_header：一次 DNS 波动或临时读超时就触发 stale，会把本可成功的请求也降级，掩盖真实问题 - 若后端常因进程崩溃导致 connection refused，
error是合理选择；若只是偶发超时，优先调优proxy_connect_timeout和proxy_read_timeout，而非扩大 stale 范围
确保 error 响应本身能进缓存，后续才能托底
很多人配了 error 却发现托底不生效，根本原因是：Nginx 默认不缓存 5xx 或 error 响应。必须显式告诉它“把错误也存下来”：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
-
proxy_cache_valid 502 503 504 1m;—— 让错误响应至少缓存 1 分钟，为后续 stale 提供内容来源 -
proxy_cache_valid any 10s;（可选兜底）—— 防止其他未列明状态码（如 500、000）完全无法进缓存 - 没有这一步，哪怕 upstream 返回了 503，Nginx 也不会存，等真正 error 触发时，本地根本没有“旧内容”可返
缓存必须存在、稳定、未被清理
stale 不生成内容，只授权使用。托底失败往往源于缓存链路断裂：
-
缓存区域必须定义并启用：http 块中要有
proxy_cache_path /var/cache/nginx keys_zone=my_cache:10m;，location 中要有proxy_cache my_cache; -
缓存键必须稳定：用
proxy_cache_key "$scheme$host$request_uri";，剔除$args、$cookie、$time_iso8601等动态字段，否则同一接口每次生成不同 key，error 响应存了一个 key，而下次请求命中另一个 key，依然无缓存可用 -
inactive 时间不宜过短：例如
inactive=30s，若流量稀疏，缓存可能刚存几秒就被清理，托底自然失效
验证托底是否真实生效
不能只看状态码是不是 200，要确认用户实际拿到的是旧数据：
- 停掉 upstream（如
systemctl stop app-server），发起请求 - 响应头中出现
X-Cache: STALE（需提前配置add_header X-Cache $upstream_cache_status;） - 响应体与故障前完全一致（比如 JSON 字段、HTML 结构、图片二进制），不是空页、不是 Nginx 默认 502 页面
- 响应耗时在几十毫秒内（远低于
proxy_read_timeout），说明确实绕过了回源，没卡在等待上游
