proxy_cache_use_stale 本身不提供后端恢复保护，仅被动返回陈旧缓存；真正的恢复衔接依赖 proxy_cache_background_update、proxy_cache_lock 和 proxy_cache_valid 三者协同实现。
proxy_cache_use_stale 本身不提供“后端恢复保护”，它只负责在后端出错时返回已有的旧缓存——它不管后端是否在恢复、何时恢复，也不主动探测或干预后端状态。所谓“保护”，其实是靠它配合其他指令构建的一套响应机制：当后端暂时不可用，Nginx 不中断服务，而是用旧内容顶上，同时悄悄尝试更新缓存，等后端一恢复，新内容自然就回来了。
它不感知恢复，只响应失败
proxy_cache_use_stale 是被动触发的。它只看当前这次请求与后端交互的结果：连接失败、超时、收到 502/503/504 等，就决定是否启用陈旧缓存。它不会定时轮询后端、不会记录故障持续时间、也不会在后端恢复后自动清空旧缓存或强制刷新。恢复与否，对它没有意义。
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 后端宕机中 → 返回 STALE 响应（如果缓存存在）
- 后端刚恢复但还没被 Nginx 拉到新内容 → 仍可能返回 STALE（取决于 background_update 是否完成）
- 后端已恢复且 background_update 成功 → 下一个请求大概率命中 HIT，返回新鲜内容
真正起“恢复衔接”作用的是配套机制
让旧缓存托底和新内容回归无缝衔接，关键不在 proxy_cache_use_stale 本身，而在它依赖的三个协同动作：
- proxy_cache_background_update on：返回 stale 的同时，Nginx 自动发起一个低优先级子请求去 upstream 拉新数据。后端一恢复，这个子请求就能成功，新内容就写进缓存了
- proxy_cache_lock on：避免大量并发请求在缓存过期瞬间一起涌向后端。第一个请求触发 background_update，其余等待或继续走 stale，减轻上游压力，也给恢复留出窗口
- proxy_cache_valid 覆盖 5xx：比如 proxy_cache_valid 502 503 504 1m；确保后端返回错误时也进缓存——这样后续 stale 才有“旧内容”可返，也为 background_update 提供了初始缓存键
验证它是否在“衔接恢复”而不是假装正常
停掉后端后，别只看是否返回了数据，重点观察三件事：
- 响应头含 X-Cache: STALE（需提前配置 add_header X-Cache $upstream_cache_status;）
- 响应体内容与故障前完全一致（不是空页、不是默认错误页）
- 后台日志或监控能看到 background_update 请求在后端恢复后成功回源并更新缓存
