通过map精准识别静态资源并隔离缓存区，结合proxy_cache_use_stale按故障信号动态启用stale，实现关键静态资源高可用降级，支持后台静默更新与实时验证。
直接用 proxy_cache_use_stale 结合 map 实现静态服务高可用降级，核心是“按需启用 stale + 按信号控制缓存策略”，不是全局兜底，而是让关键静态资源（如 HTML 模板、JS/CSS、图片）在源站不可用时，仍能稳定返回已缓存内容，并支持动态调整降级粒度。
精准识别静态资源并隔离缓存策略
静态服务通常路径固定、响应稳定，适合用 map 提前分类，避免和动态接口混用同一缓存区：
- 用
map $request_uri $is_static匹配常见静态后缀：.html、.js、.css、.png、.jpg等，命中则设为"1"，否则"0" - 在
location中用if ($is_static = "1") { proxy_cache static_cache; }显式启用专用缓存区（如keys_zone=static_cache:10m），与动态接口物理隔离 - 避免用
proxy_cache off或if做全量跳过——这会切断整个缓存链路，stale 就失去作用基础
为静态资源定制 stale 触发条件
静态内容不常更新，但对可用性要求极高；源站宕机时，应优先信任已缓存的旧文件，而非等待超时：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 只启用明确的故障信号：
proxy_cache_use_stale error http_502 http_503 http_504;—— 连接失败或网关错误才触发 stale，不加timeout防止网络抖动误降级 - 配合
proxy_cache_valid覆盖所有常见状态码：proxy_cache_valid 200 301 302 1h;（正常内容）、proxy_cache_valid 404 10m;（缺失页也缓存）、proxy_cache_valid 502 503 504 30m;（错误响应也进缓存，后续可被 stale 复用） - 静态资源的
proxy_cache_key必须稳定：proxy_cache_key "$scheme$host$request_uri";，禁用$args和随机参数，确保相同 URL 总是命中同一缓存项
用 map 动态放宽 stale 条件应对突发场景
当检测到源站压力升高或主动维护时，可临时增强降级能力，无需 reload 配置：
- 定义
map $upstream_http_x_health $stale_level：后端在响应头中带X-Health: degraded时，映射为"error timeout http_502 http_503 http_504"；正常时为"http_502 http_503 http_504" - 在 location 中写：
proxy_cache_use_stale $stale_level;—— Nginx 会自动解析变量值并生效 - 搭配
proxy_cache_background_update on;：stale 返回的同时，后台静默拉取新内容，用户无感知过渡
验证是否真正达成高可用降级
不能只看配置是否写对，要确认客户端拿到的是“可用的旧内容”：
- 停掉上游静态服务（如
systemctl stop nginx-static），发起请求，检查响应头是否有X-Cache: STALE（需提前加add_header X-Cache $upstream_cache_status;） - 对比故障前后响应体：HTML 是否完整渲染、JS 是否能执行、图片是否正常显示，而不是返回空页或 Nginx 默认 502 页面
- 响应耗时应在 10–50ms 内（远低于
proxy_read_timeout），说明完全绕过了回源
