nginx 实现后端宕机时旧缓存托底，需精准配置 proxy_cache_use_stale 仅响应 500/502/503/504 状态码，配合 proxy_cache_path、proxy_cache_key、proxy_cache_valid 等确保缓存“存得住、找得着、过得了期”，并启用 background_update 与 cache_lock 实现边服务边恢复。

Nginx 实现后端宕机时旧缓存托底，关键不是打开 proxy_cache_use_stale 就完事，而是让它在正确时机、对正确内容、以正确方式被启用。它不生成数据，只授权复用已存在但过期的缓存——前提是这条链路早已就位。

CPA Update - Secure CLI Proxy API Maintenance

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

下载

只响应真正可信的宕机信号
后端进程退出、服务崩溃或网关拦截时，最稳定的表现是返回 500/502/503/504。这些状态码由应用层主动发出，语义明确、误判率低：

• 写 proxy_cache_use_stale http_500 http_502 http_503 http_504;
• 不加 error 或 timeout：连接中断、DNS 波动、单次读超时属于网络抖动，不是节点宕机，盲目启用会掩盖真实问题
• 如需后台刷新，可追加 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、$time_iso8601、$request_id 等动态字段
• 让错误响应也进缓存：proxy_cache_valid 500 502 503 504 1m;——没有这句，5xx 根本不会落盘，stale 就无旧内容可返
• 缓存有效期不宜过短：若接口缓存仅设 10s，还没等故障发生就被清理，stale 自然失效

让托底不止于“返回旧内容”，而是“边服务边恢复”
单纯返回陈旧响应只是起点，优雅托底的核心在于平滑过渡：

• 开启异步刷新：proxy_cache_background_update on; —— 返回 stale 的同时，Nginx 自动发起子请求拉新内容并写入缓存
• 防止并发击穿：proxy_cache_lock on; proxy_cache_lock_timeout 3s; —— 同一 key 下，首个请求负责回源或触发后台更新，其余等待后直接读新缓存或继续走 stale
• 二者必须配合：没有 background_update，updating 条件永不满足；没有 cache_lock，多个并发可能同时刷爆上游

验证是否真在优雅托底，别只看状态码
停掉所有 upstream 后，从客户端视角确认三件事：

• 响应头含 X-Cache: STALE（需提前配置 add_header X-Cache $upstream_cache_status;）
• 响应体与故障前完全一致，不是空页、不是 Nginx 默认 502 页面、也不是结构错乱的 JSON
• 响应耗时在几十毫秒内（如 proxy_read_timeout 3s，实测 40–80ms），说明确实绕过了回源

不复杂但容易忽略