Nginx 通过 proxy_cache_use_stale 实现类熔断的缓存兜底：需精准配置 error http_502 http_503 http_504 触发条件，确保缓存区定义、key 稳定、5xx 响应被缓存，并配合 background_update 和 cache_lock 实现边服务边更新。
只开真正需要的 stale 触发条件
后端宕机时，典型表现是连接失败或返回网关错误。应精准启用对应参数，避免把网络抖动也当成崩溃：
-
必须加：
error（覆盖连接拒绝、上游重置等底层中断） +http_502/http_503/http_504（标准服务不可用信号） -
不建议加：
timeout（单次读超时可能是瞬时抖动）和http_500（多数宕机不会主动返回 500，而是直接断连） -
如需后台刷新：可加
updating，但必须同步开启proxy_cache_background_update on;
确保老数据“存得住、找得准、用得上”
stale 不生成数据，只复用已有的。以下三点缺一不可：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 缓存区已正确定义并被引用：
proxy_cache_path配好路径与keys_zone，location 中显式写proxy_cache my_cache; - cache key 稳定：
proxy_cache_key "$scheme$host$uri";—— 剔除?t=、?v=、随机参数、Cookie 等干扰字段，否则同一页面会散列成多个 key - 错误响应也要进缓存：
proxy_cache_valid 502 503 504 1m;，否则后端返回 503 时根本不会落盘，后续 stale 就无内容可返；主响应也需设合理有效期，比如proxy_cache_valid 200 301 302 10m;
让兜底更可靠：后台更新 + 请求锁
单纯返回旧数据只是第一步。要让用户无感过渡到新内容，还需两层保障：
- 开启异步刷新：
proxy_cache_background_update on;—— Nginx 在返回 stale 的同时，自动发起低优先级子请求拉取新响应并写入缓存 - 防止并发击穿：
proxy_cache_lock on;+proxy_cache_lock_timeout 3s;—— 同一 key 下，首个请求负责回源或触发后台更新，其余请求最多等待 3 秒后直接读新缓存（或继续走 stale）
验证是否真在吐老数据，而不是假装正常
别只看状态码是不是 200。停掉 upstream 后，从客户端视角确认三件事：
- 响应头中出现
X-Cache: STALE（需提前配置add_header X-Cache $upstream_cache_status;） - 响应体（HTML 或 JSON）和故障前完全一致，不是空页、不是 Nginx 默认 502 页面、也不是错误提示 JSON
- 响应耗时在 20–100ms 级别（远低于
proxy_read_timeout，比如设为 3s），说明确实绕过了回源
