能实现“无感”降级，即用户不看到错误页、不遭遇超时、内容可读可用，依赖提前部署的缓存降级链路；需精准配置 proxy_cache_use_stale、可靠缓存区、稳定 cache_key、缓存 5xx 响应及后台静默刷新等机制。
能实现，但“无感”不等于零延迟，而是指用户不看到错误页、不遭遇超时、内容可读可用——这依赖一套提前部署好的缓存降级链路，不是故障发生后才启用的补救措施。
只启用真正可信的 stale 触发条件
后端全盘雪崩时，典型表现是连接中断或返回标准网关错误。必须精准匹配这些信号，避免把瞬时抖动误判为崩溃：
- 写入 proxy_cache_use_stale error http_502 http_503 http_504：其中
error覆盖上游拒绝连接、重置连接等底层失败；502/503/504 是网关层明确宣告服务不可用的 HTTP 状态码 - 不加
timeout：单次读超时可能是网络抖动，非雪崩特征，加入后易导致本可成功的请求也走 stale - 不加
invalid_header：响应头异常多由中间设备（如 WAF、CDN）引起，与后端雪崩无关 - 如需后台静默刷新，可追加
updating，但必须同步开启 proxy_cache_background_update on
确保过期缓存“存得住、找得准、用得上”
stale 生效的前提是：该页面曾成功缓存过，当前仍存在于磁盘，且 key 未漂移、过期时间可识别。
- 定义可靠缓存区：proxy_cache_path /var/cache/nginx/pages levels=1:2 keys_zone=pages_cache:128m inactive=7d use_temp_path=off
- 在 location 中启用：proxy_cache pages_cache
- 稳定 cache_key：proxy_cache_key "$scheme$host$uri"——剔除
?t=、?v=、utm_等动态参数，防止同一页面生成多个 key - 必须缓存 5xx 响应：proxy_cache_valid 502 503 504 1m——否则后端返回 503 时根本不会进缓存，后续 stale 就无数据可返
- 主响应设合理有效期：proxy_cache_valid 200 301 302 30m——确保页面有足够时间进入“已过期但可用”状态，又不至于过长导致信息严重滞后
让降级更平滑：旧内容返回 + 新内容静默更新
单纯返回旧页面只是第一步。要达成“无感”，需让用户在看到旧内容的同时，后台已悄然拉取新数据。
- 开启 proxy_cache_background_update on：Nginx 在返回 stale 的同时，自动发起异步子请求刷新缓存
- 启用 proxy_cache_lock on 和 proxy_cache_lock_timeout 3s：防止缓存失效瞬间大量并发请求集体击穿后端
- 暴露状态便于验证：add_header X-Cache $upstream_cache_status——后续可通过响应头判断是否命中 stale
验证是否真生效：从用户视角确认三件事
停掉所有 upstream（如 systemctl stop app-server）后，发起真实请求，检查：
- 响应头中出现 X-Cache: STALE
- 响应体（HTML 源码）与雪崩前完全一致，不是 Nginx 默认 502 页面、不是空响应、也不是 JSON 错误体
- 响应耗时在 20–100ms 级别（远低于
proxy_read_timeout，比如设为 3s），说明确实绕过了回源
