Nginx在后端崩溃时返回陈旧缓存依赖proxy_cache_use_stale指令与缓存链路协同：需明确配置500/502/503/504触发、确保缓存已定义且5xx响应被缓存、配合background_update和cache_lock实现边服务边更新。
Nginx 在后端崩溃时能返回陈旧缓存，靠的不是单个指令，而是 proxy_cache_use_stale 与缓存基础链路协同工作的结果。它不生成数据，只在特定失败条件下“授权使用”已存在但过期的缓存项。配置对了，用户看到的是毫秒级响应；配错了，照样返回 502。
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
精准启用 stale 触发条件
`proxy_cache_use_stale` 必须明确指向后端主动发出的、语义清晰的崩溃信号： - 推荐写法：`proxy_cache_use_stale http_500 http_502 http_503 http_504;` 这四类状态码由应用层返回，说明服务进程仍在运行但逻辑异常，可信度最高。 - 不建议加 `error` 或 `timeout`：连接拒绝、DNS 超时、TCP 重置等属于网络层抖动，可能瞬时恢复，盲目启用会掩盖真实问题，导致本可成功的请求也被降级。 - 如需后台静默刷新，可追加 `updating`，但必须同步开启 `proxy_cache_background_update on;`，否则该参数完全无效。确保缓存“有得用、找得着、过得了期”
stale 是复用者，不是创造者。以下三点缺一不可： - 缓存区已定义且被引用：`http` 块中配置 `proxy_cache_path /var/cache/nginx keys_zone=my_cache:512m inactive=3d use_temp_path=off;`，并在 `location` 中显式写 `proxy_cache my_cache;` - 缓存键稳定：用 `proxy_cache_key "$scheme$host$request_uri";`，剔除 `$args`、`$cookie_`、时间戳、随机数等动态字段，避免同一资源被拆成多个 key - 错误响应也要进缓存：必须加 `proxy_cache_valid 500 502 503 504 1m;`，否则 5xx 响应根本不会落盘，后续 stale 就无内容可返 - 缓存有效期不宜过短：若关键接口缓存仅设 `10s`，还没等故障发生就已被 `inactive` 清理，stale 自然失效让托底更可靠：后台更新 + 请求锁
单纯返回旧内容只是第一步，真正可用的托底需要“边服务、边恢复”： - 开启异步刷新：`proxy_cache_background_update on;` Nginx 在返回 stale 的同时，自动发起低优先级子请求拉取新响应并写入缓存；失败不影响当前响应 - 防止并发击穿：`proxy_cache_lock on; proxy_cache_lock_timeout 3s;` 同一缓存键下，首个请求负责回源或触发后台更新，其余请求等待最多 3 秒后直接读新缓存（或继续走 stale），避免上游被压垮从客户端视角验证是否真托底成功
停掉上游服务后，检查三个硬指标： - 响应头中出现 `X-Cache: STALE`（需提前配置 `add_header X-Cache $upstream_cache_status;`） - 响应体与故障前完全一致，不是空页、不是 Nginx 默认 502 页面、也不是结构错乱的 JSON - 响应耗时在几十毫秒内（例如 `proxy_read_timeout 3s`，实测返回 40–80ms），说明确实绕过了回源校验不复杂但容易忽略。
