proxy_cache_use_stale 在源站宕机时可安全返回过期缓存，需精准配置触发条件（如http_500-504）、确保缓存已就绪（keys_zone、cache_key、cache_valid），并搭配background_update与cache_lock提升体验，最后通过X-Cache头和响应验证实效。
当后端源站宕机时，proxy_cache_use_stale 能让 Nginx 主动跳过回源校验，直接返回本地已缓存但已过期的内容——这不是“凑合用”，而是有策略的可用性保障。关键在于配置精准、链路完整、验证到位。
只启用真正需要的 stale 触发条件
源站宕机通常表现为连接失败、超时或明确返回 5xx。应避免大而全地开启所有参数：
- 明确指定
http_500 http_502 http_503 http_504，确保仅在后端真实报错时启用降级 - 慎用
error和timeout：网络抖动或临时超时可能误触发 stale，反而掩盖真实问题 - 如需缓解缓存刷新瞬间的并发压力，可额外加上
updating，但必须配合proxy_cache_background_update on
确保缓存本身“存在且可复用”
stale 不是魔法开关，它依赖缓存系统已就绪。常见失效原因及修复方式：
-
proxy_cache_path必须已定义 keys_zone（如my_cache），且location中通过proxy_cache my_cache显式引用 -
proxy_cache_key避免含易变字段（如时间戳、随机参数、用户 ID），推荐用$scheme$host$request_uri保证相同请求命中同一缓存项 -
proxy_cache_valid必须覆盖 5xx 响应，例如加一句proxy_cache_valid 500 502 503 504 1m;，否则错误响应根本不会进缓存，后续无法 stale 复用
搭配后台更新与锁机制提升体验
单纯返回旧内容只是第一步。更优做法是让用户无感过渡到新数据：
- 启用
proxy_cache_background_update on;：Nginx 在返回 stale 响应的同时，自动发起异步子请求刷新缓存 - 开启
proxy_cache_lock on;并设合理超时（如proxy_cache_lock_timeout 3s;）：防止大量并发请求在缓存失效瞬间集体击穿源站 - 对核心接口，可提供手动刷新入口（如带签名的
/cache/flush?uri=/api/data），便于运维快速干预
从客户端视角验证是否真实生效
别只看日志或状态码，要确认用户实际拿到的是什么：
- 停掉上游服务（如
systemctl stop app-server），发起请求，检查响应头中是否有X-Cache: STALE（需提前配置add_header X-Cache $upstream_cache_status;） - 对比故障前后响应体是否一致，确认返回的是原样旧内容，而非空响应、默认 50x 页面或 JSON 错误结构
- 响应耗时应在几十毫秒内（远低于
proxy_read_timeout），说明确实绕过了回源，未等待后端
