proxy_cache_use_stale 是容灾开关而非故障补救，仅在后端真实宕机（如连接中断、502/503/504）时安全复用缓存；需配合有效缓存配置、稳定key、5xx缓存策略及后台更新机制，确保用户无感访问并持续刷新。
proxy_cache_use_stale 不是“故障后补救”，而是灾难发生时让用户无感继续访问的容灾开关——它不修复后端，只确保缓存能被安全复用。
精准触发：只响应真实宕机信号
后端真正崩溃时，最常见表现是连接中断或返回网关级错误，而非随机 500。应严格限定触发条件：
-
必须启用：
error（覆盖连接拒绝、上游重置、DNS 失败等底层中断） -
必须启用：
http_502 http_503 http_504（标准服务不可用语义，如网关超时、服务未就绪、上游无响应） -
不建议启用：
timeout（单次读超时可能是瞬时抖动，非节点宕机） -
慎用：
http_500（多数崩溃直接断连，不会主动返回 500；若确认应用层稳定输出 500，再加入）
缓存本身要“存得住、找得准、过得了期”
stale 只是授权使用旧数据，前提是旧数据真实存在且可命中：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 缓存区已定义并启用：
proxy_cache_path /var/cache/nginx/mycache levels=1:2 keys_zone=mycache:128m inactive=1h use_temp_path=off;，且 location 中明确写proxy_cache mycache; - cache key 稳定：
proxy_cache_key "$scheme$host$request_uri";，剔除$args、?t=、?v=、$cookie_等动态干扰字段 - 5xx 响应必须进缓存：
proxy_cache_valid 502 503 504 1m;，否则后端返回 503 时根本不会落盘，stale 就无内容可返 - 主响应也要设合理有效期：
proxy_cache_valid 200 301 302 10m;，避免缓存刚生成就被 inactive 清理
边服务边恢复：避免静默陈旧
返回旧数据只是起点，关键是要在用户无感知前提下完成更新：
- 开启后台刷新：
proxy_cache_background_update on;→ 返回 stale 的同时，Nginx 自动发起子请求拉新内容 - 防止并发击穿：
proxy_cache_lock on;+proxy_cache_lock_timeout 3s;→ 同一 key 下，首个请求负责回源或触发后台更新，其余请求等待或继续走 stale - 暴露状态便于验证：
add_header X-Cache $upstream_cache_status;→ 故障时看到X-Cache: STALE才说明机制生效
验证是否真在容灾，而非假装正常
停掉 upstream 后，从客户端视角确认三件事：
- 响应状态码仍是 200（或原状态），不是 502/503 页面
- 响应头含
X-Cache: STALE - 响应体内容与故障前完全一致（不是空页、不是默认错误页、不是 JSON 错误结构）
