proxy_cache_use_stale 需协同缓存基础、错误处理与后台更新才生效；仅对500/502/503/504启用，配合proxy_cache_valid缓存错误响应、proxy_cache_background_update on和proxy_cache_lock on实现无感过渡，并通过x-cache头、响应一致性及低延迟验证效果。
只对可信的崩溃信号启用 stale
后端真正宕机时，最明确的表现是返回 500、502、503、504 这四类状态码。它们由后端主动发出，语义清晰、误判率低。
- 推荐配置：
proxy_cache_use_stale http_500 http_502 http_503 http_504; - 避免加
error或timeout：网络抖动、瞬时超时可能只是临时问题，盲目启用会把陈旧内容当“救命稻草”返回，掩盖真实异常 - 如需支持缓存过期后立即返回旧内容并后台刷新，必须加上
updating，且同步开启proxy_cache_background_update on;
确保缓存本身“存得住、找得着、过得了期”
stale 不生成缓存，只复用已存在但过期的内容。缺了下面任何一环，stale 就无数据可返：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 定义缓存区：
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:512m inactive=3d use_temp_path=off; - 在 location 中启用：
proxy_cache my_cache; - 使用稳定缓存键：
proxy_cache_key "$scheme$host$request_uri";（去掉$args、时间戳、用户 ID 等动态字段） - 让错误响应也能进缓存：
proxy_cache_valid 500 502 503 504 1m;（否则 5xx 根本不缓存，stale 就没东西可用）
搭配后台更新与请求锁，实现自动恢复
返回陈旧内容只是第一步，关键是要让用户无感过渡到新内容：
-
proxy_cache_background_update on;：stale 响应返回的同时，Nginx 自动发起子请求拉新内容写入缓存 -
proxy_cache_lock on;+proxy_cache_lock_timeout 3s;：同一缓存键只允许一个请求回源，其余直接返回 stale 或刚刷新好的内容 - 二者必须共存：没有
background_update，updating条件永不满足；没有cache_lock，高并发下可能瞬间打爆上游
从客户端视角验证是否真生效
停掉 upstream 后，别只看 HTTP 状态码，重点确认三件事：
- 响应头中出现
X-Cache: STALE（需提前配置add_header X-Cache $upstream_cache_status;） - 响应体与故障前完全一致——不是空页、不是 Nginx 默认 502 页面、也不是格式错乱的 JSON
- 响应耗时在几十毫秒内（比如
proxy_read_timeout 3s，实测返回 40–80ms），说明确实绕过了回源
