proxy_cache_use_stale 配置无效通常因缓存决策链断裂，须同时满足：上游缓存已存在且key稳定、proxy_cache_valid覆盖对应状态码（如503）、proxy_cache_use_stale含error或http_50x、proxy_cache_background_update与proxy_cache_lock正确启用，并通过X-Cache-Status: STALE及响应一致性验证生效。
proxy_cache_use_stale 配置无效，通常不是“没写对”，而是整个缓存决策链断在某个环节——它不单独起作用，必须依赖上游缓存存在、key 稳定、过期策略明确、后台机制就位。排查要从“有没有旧内容可返”和“Nginx 是否被授权用它”两个角度切入。
确认缓存本身是否真存在且可命中
stale 是“用旧的”，前提是得有旧的。如果缓存压根没存进去，或存了但 key 对不上，stale 就无从谈起：
- 检查 proxy_cache_valid 是否为对应状态码设了有效期：比如后端返回 503，但你只写了
proxy_cache_valid 200 10m，那 503 响应根本不会进缓存，后续再配http_503也没数据可用 - 验证 cache key 是否稳定：用
log_format打印实际 key，例如：log_format cache_debug '$remote_addr - "$upstream_cache_key"';
然后查 access.log，看同一资源（如/api/user）的请求是否生成相同 key。若含未过滤的$args或$cookie_session，key 就会散列，导致“看起来是同一个接口，实则缓存互不相干” - 确认 proxy_cache_path 和 proxy_cache 已启用且名称一致：比如
keys_zone=mycache:10m，location 中必须写proxy_cache mycache；漏掉proxy_cache或名字拼错，整个缓存模块就不工作
验证 stale 触发条件是否真正满足
Nginx 只在特定错误信号下才走 stale 路径，不是所有异常都触发。重点看后端真实崩溃时 Nginx 能否捕获到它认可的信号：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 停掉 upstream 后，用 curl 测试，观察响应头：
添加add_header X-Cache-Status $upstream_cache_status;
若返回的是502或超时，且X-Cache-Status是MIS或空，说明根本没进入 stale 流程 - 检查 proxy_cache_use_stale 参数是否包含
error：这是覆盖连接拒绝、上游重置等底层中断的关键项。只写http_502不够——很多宕机表现是直接断连，不发 502 - 避免误加
timeout：单次读超时（如proxy_read_timeout 3s内没回包）属于瞬时抖动，不应作为容灾依据；加了反而可能让轻微延迟就被当作故障，放大 stale 使用范围
检查响应是否真的来自 stale，而非其他路径
即使配置全对，也可能因干扰项掩盖真实行为。需排除常见“假象”：
- 前端或浏览器带了
Cache-Control: no-cache或Pragma: no-cache：Nginx 默认会跳过缓存逻辑，stale 自然不生效。测试时用 curl 并显式清除请求头：curl -H "Cache-Control:" -H "Pragma:" http://your.site/api - 响应头中没有
X-Cache-Status: STALE？说明 Nginx 没走 stale 分支。此时要回头确认：后端是否真返回了 502/503？还是返回了 200 但内容异常？stale 只对明确错误码或 error 事件响应，不对业务错误兜底 - 查看 error.log 中是否有
upstream timed out或connection refused日志：这是error触发的证据；若只有upstream prematurely closed connection，可能需要补上http_502或调整 upstream 健康检查
验证后台更新是否配合到位（尤其 updating 场景）
如果用了 updating 却发现失效后用户卡住或返回 504，问题大概率出在后台刷新没启动：
-
proxy_cache_background_update on; 必须显式开启：只配
proxy_cache_use_stale updating不会自动触发后台拉新，这个开关是“允许用过期内容 + 同时后台更新”的联合许可 - 确保 proxy_cache_lock on; 已启用：否则多个请求同时命中过期 key，会各自尝试回源，造成并发击穿，部分请求可能超时失败，掩盖了 stale 的本意
- 用 ab 或 wrk 发起并发请求（如
ab -n 100 -c 20），观察响应头：
若首次请求返回X-Cache-Status: EXPIRED，后续请求快速返回UPDATING或STALE，说明机制跑通；
若全是MISS或长时间等待后返回504，说明 background_update 未生效或锁配置缺失
