proxy_cache_use_stale 仅允许返回已存在但过期的缓存内容，需同时配置 proxy_cache_path、proxy_cache 和 proxy_cache_valid（含5xx），并仅启用 http_500/502/503/504 等高可信触发条件，配合稳定 proxy_cache_key 与 X-Cache-Status 验证生效。
直接启用 proxy_cache_use_stale 不会让 Nginx “主动失效再服务”，它只在特定错误发生时，允许返回**已存在但已过期**的缓存内容。关键不是让它“失效”，而是让它“敢用旧的”——前提是缓存本身已存在、可识别、且触发条件精准。
必须配齐三项基础缓存配置
单独写 proxy_cache_use_stale 没有效果，以下三者缺一不可：
-
定义缓存区：在
http块中声明路径与内存区，例如：proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=mycache:10m max_size=1g inactive=1h; -
启用缓存作用域：在
location中指定使用哪个缓存区，例如：proxy_cache mycache; -
设定缓存有效期：明确哪些状态码缓存多久，必须覆盖 5xx（否则旧响应根本不会进缓存）：
proxy_cache_valid 200 302 10m;proxy_cache_valid 500 502 503 504 1m;
只启用高可信度的 stale 触发条件
后端崩溃最稳定的表现是返回 5xx，而不是连接失败或超时。应聚焦语义明确、误判率低的状态：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 推荐写法：
proxy_cache_use_stale http_500 http_502 http_503 http_504; - 避免写
error或timeout：网络抖动可能瞬时恢复，盲目启用会掩盖真实问题 - 如需后台自动刷新新内容，必须加上
updating，且同步开启proxy_cache_background_update on;
确保缓存键稳定、内容可复用
stale 不生成缓存，只复用已有缓存。若缓存键含随机参数或 Cookie，很可能每次请求都算“新键”，导致无旧内容可用：
- 用稳定键，例如：
proxy_cache_key "$scheme$host$request_uri";（剔除$args、时间戳、用户标识等动态字段） - 确保后端对同一 URI 返回一致响应体（不能一会儿 JSON，一会儿 HTML）
- 配合
proxy_cache_lock on;和proxy_cache_lock_timeout 3s;，防止并发击穿时多个请求同时回源
上线后验证是否真生效
停掉所有 upstream 后，别只看返回了 200，重点确认三件事：
- 响应头中出现
X-Cache-Status: STALE（需提前加：add_header X-Cache-Status $upstream_cache_status;） - 响应体内容与故障前完全一致（不是空页、不是默认 502 页面、也不是结构错乱）
- 响应耗时仍为毫秒级（说明没卡在等待后端，确实在读本地缓存）
