关键在于用proxy_next_upstream与proxy_cache_use_stale协同实现上游故障时自动返回陈旧缓存并后台刷新，仅对error/timeout/http_502-504启用stale，配合updating、proxy_cache_valid及error_page兜底，屏蔽Vary头并合理设置cache_inactive。

关键在于让 upstream 的故障信号直接触发缓存层的“降级响应+后台刷新”动作，而不是等错误冒泡到客户端再处理。核心配置围绕 proxy_next_upstream 和 proxy_cache_use_stale 协同展开。

明确触发条件：哪些错误要走缓存回退

不是所有上游异常都适合返回陈旧缓存。需精准定义可接受的“软失败”类型：

• error：连接后端失败（如 TCP 连接被拒、RST）
• timeout：连接或响应超时（建议配合 proxy_connect_timeout / proxy_read_timeout 合理设值）
• http_502、http_503、http_504：网关类错误，表明后端已不可用或过载
• 避免加入 http_500：它可能是业务逻辑错误，返回陈旧缓存反而掩盖问题

启用 stale 缓存：允许返回过期内容并异步刷新

proxy_cache_use_stale 是联动的执行开关。它必须与 proxy_next_upstream 中声明的错误类型严格一致：

CPA Update - Secure CLI Proxy API Maintenance

安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。

下载

• 配置示例：proxy_cache_use_stale error timeout updating http_502 http_503 http_504;
• updating 很关键：当缓存正被后台更新时，新请求仍可返回旧版本，避免“缓存雪崩”式阻塞
• 确保 proxy_cache_valid 已设置基础有效期（如 200 301 302 10m），否则无“stale”可言

兜底闭环：缓存也失效时转向静态响应

当上游全挂且缓存本身过期/未命中时，需有最终 fallback：

• 用 error_page 502 503 504 = @degrade 捕获错误流
• 在 @degrade location 中返回预置 HTML、JSON 或重定向到维护页
• 注意：该兜底响应不应被缓存（加 add_header Cache-Control "no-store, no-cache";）

辅助控制：防止误缓存和健康度干扰

几个容易忽略但影响实效的细节：

• 禁用 Vary 头干扰缓存键：若后端返回 Vary: User-Agent，会导致缓存碎片化；可在 Nginx 中用 proxy_hide_header Vary; 屏蔽
• 设置合理 proxy_cache_inactive（如 10m）：避免长期未访问的缓存条目堆积
• 不给兜底响应配缓存：避免把维护页也缓存住，导致故障恢复后用户仍看到错误页