proxy_cache_use_stale 专用于后端真实故障时复用已过期缓存，非为抗抖动设计；抖动属瞬态异常，盲目启用 error/timeout 会误降级可用请求；应仅对 500/502/503/504 启用 stale，配合 cache_path、稳定 cache_key、cache_valid 及 background_update + cache_lock 实现平滑抗抖。
proxy_cache_use_stale 本身不是为“抗抖动”设计的，它专用于后端**真实故障时复用已过期缓存**。抖动（如瞬时超时、DNS波动、连接拒绝）属于短暂异常，盲目启用 error 或 timeout 会把本可成功的请求降级，反而损害可用性。要真正抗抖动，得区分场景、精准配置，并补足基础链路。
只对可信崩溃信号启用 stale
抖动 ≠ 崩溃。Nginx 应只在后端明确不可用时才走陈旧缓存：
-
必须启用：
http_500 http_502 http_503 http_504——这些是后端主动返回的状态码，语义清晰、误判率低 -
不建议启用：
error和timeout——连接被拒、DNS失败、单次读超时多属网络瞬态问题，开启后可能让刚恢复的请求也返回旧数据 -
慎加 updating：若需缓存过期后立即返旧+后台刷新，可加
updating，但必须同步打开proxy_cache_background_update on
确保缓存“有得用、找得着、过得了期”
stale 不生成内容，只复用已有缓存项。以下三点缺一不可：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 缓存区已正确定义并被引用：
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:512m inactive=3d use_temp_path=off;，且 location 中写proxy_cache my_cache; - 缓存键稳定：
proxy_cache_key "$scheme$host$request_uri";，剔除$args、时间戳、随机参数、$cookie_等干扰字段 - 错误响应也要进缓存：
proxy_cache_valid 500 502 503 504 1m;，否则 503 根本不落盘，后续 stale 就无内容可返
用 background_update + cache_lock 实现平滑过渡
返回旧内容只是起点，抗抖动的关键是避免“旧内容长期静默”，同时防止并发击穿：
-
proxy_cache_background_update on;：返回 stale 的同时，Nginx 自动发起低优先级子请求拉新响应并写入缓存 -
proxy_cache_lock on; proxy_cache_lock_timeout 3s;：同一缓存键下，仅首个请求回源或触发更新，其余最多等 3 秒后直接读新缓存或继续走 stale
从客户端视角验证是否真抗抖动
模拟抖动（如临时停 upstream、人为注入 503）后，检查三件事：
- 响应头含 X-Cache: STALE（需提前配
add_header X-Cache $upstream_cache_status;） - 响应体与抖动前完全一致，不是空页、不是 Nginx 默认错误页、也不是结构错乱的 JSON
- 响应耗时在几十毫秒内（如 40–80ms），远低于
proxy_read_timeout，说明确实绕过了回源
