nginx 用 proxy_cache_use_stale 实现后端宕机时返回旧缓存，需构建“缓存存得住、找得准、错得进、stale 用得上”完整链路：精准配置 error/502-504 触发条件，确保 proxy_cache_path、稳定 cache_key 和 5xx 缓存生效，并配合 background_update 与 cache_lock 提升可靠性，最终通过 x-cache 响应头验证 stale 状态。
直接用 proxy_cache_use_stale 让 Nginx 在后端挂掉时返回旧缓存，核心不是“加个参数就生效”，而是构建一条“缓存存得住、找得准、错得进、 stale 用得上”的完整链路。它不修复后端，只稳住用户侧——前提是旧内容真在磁盘上、能对上号、且被允许复用。
精准启用真正反映宕机的触发条件
后端挂掉时，最可信的信号是连接被拒或返回标准网关错误，而不是所有异常都兜底：
-
必须加：
error（覆盖 connection refused、reset by peer 等底层中断） +http_502/http_503/http_504（服务不可用的标准状态码） -
慎加：
timeout（单次读超时可能是瞬时抖动，非真正宕机） -
按需加：
updating（配合proxy_cache_background_update on使用，避免缓存更新窗口期空白）
确保旧缓存“有得用、找得着、过得了期”
stale 不生成数据，只复用已存在的缓存项。三点缺一不可：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
-
缓存区已正确定义并启用：在
http块中配置proxy_cache_path，并在location中显式写proxy_cache mycache -
cache key 稳定可靠：用
proxy_cache_key "$scheme$host$request_uri"，剔除?t=、?v=、$cookie_、时间戳等动态字段，防止同一资源散列成多个 key -
5xx 响应必须进缓存：加
proxy_cache_valid 502 503 504 1m，否则后端返回 503 时根本不会落盘，后续 stale 就无数据可取
让托底更可靠：边返回旧内容，边静默刷新新内容
只返回老数据不够，还要让用户无感过渡到新内容：
-
开启后台更新：
proxy_cache_background_update on→ 返回 stale 的同时，Nginx 自动发起子请求拉新数据并写入缓存 -
防止并发击穿：
proxy_cache_lock on+proxy_cache_lock_timeout 3s→ 同一 key 下，首个请求负责回源或触发更新，其余最多等 3 秒后直接读缓存（或继续走 stale） -
暴露状态便于验证：
add_header X-Cache $upstream_cache_status→ 客户端看到X-Cache: STALE才算真正生效
上线前必须验证的三件事
别只看 HTTP 状态码是不是 200。停掉 upstream 后，从真实客户端视角确认：
- 响应头中是否含
X-Cache: STALE - 响应体（HTML / JSON）是否与故障前完全一致，不是空页、不是默认 502 页面
- 响应耗时是否远低于
proxy_read_timeout（比如设为 3s，实际返回在 50ms 内），说明确实绕过了回源
