proxy_cache_use_stale 用于后端故障时返回已缓存的旧内容以保障用户体验，需配合 error/502/503/504 等状态启用，确保缓存存在、key 稳定、5xx 可缓存，并通过 background_update 和 cache_lock 实现边托底边刷新。
proxy_cache_use_stale 不是让缓存“变聪明”，而是让 Nginx 在后端出问题时，敢用已有的旧内容顶上——前提是旧内容真存在、能对得上、且被允许复用。它不修复后端，只稳住用户侧体验。
精准匹配后端真实故障信号
后端宕机时，表现往往很具体：连接直接被拒（error）、网关返回 502/503/504、或干脆超时断连。但不是所有错误都该触发 stale：
- 必须加：error（覆盖 connection refused、reset by peer 等底层中断）、http_502、http_503、http_504（标准服务不可用状态码）
- 慎加：timeout（单次读超时可能是瞬时抖动，非真正宕机）、http_500（多数崩溃不会主动返回 500，而是直接断连）
- 按需加：updating（配合 proxy_cache_background_update on; 使用，避免缓存更新窗口期空白）
确保 stale 有东西可返
stale 只是“能不能用”，不是“有没有”。以下三点任缺其一，配置再全也白搭：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 缓存区已正确定义并启用：proxy_cache_path 指定路径与 keys_zone，location 中明确写 proxy_cache mycache
- cache_key 稳定可靠：proxy_cache_key "$scheme$host$request_uri" —— 剔除 ?t=、?v=、$time_iso8601、Cookie 等动态字段，防止同一资源散列成多个 key
- 5xx 响应必须进缓存：proxy_cache_valid 502 503 504 1m，否则后端返回 503 时根本不会落盘，后续 stale 就无数据可取
边托底边刷新，避免静默陈旧
只返回老数据不够，还要让用户无感过渡到新内容：
- 开启后台更新：proxy_cache_background_update on → 返回 stale 的同时，Nginx 自动发起子请求刷新缓存
- 防止并发击穿：proxy_cache_lock on + proxy_cache_lock_timeout 3s → 同一 key 下，首个请求负责回源或触发更新，其余请求最多等 3 秒后直接读缓存（或继续走 stale）
- 暴露状态便于验证：add_header X-Cache $upstream_cache_status → 客户端看到 X-Cache: STALE 才算真正生效
上线前必须验证的三件事
别只看 HTTP 状态码是不是 200。停掉 upstream 后，从真实客户端视角确认：
- 响应头中是否含 X-Cache: STALE
- 响应体（HTML / JSON）是否与故障前完全一致，不是空页、不是默认 502 页面
- 响应耗时是否远低于 proxy_read_timeout（比如设为 3s，实际返回在 50ms 内），说明确实绕过了回源
