最直接有效的测试方式是停掉上游服务，从客户端真实请求出发验证是否仍返回200响应、x-cache: stale头及内容完全一致的可用结果，同时压测确认stale占比高、耗时稳定且无大量后端错误。
最直接有效的测试方式是停掉上游服务，从客户端真实请求出发，验证是否仍能拿到可用、一致、低延迟的响应，而不是只看 Nginx 日志或状态码“看起来正常”。
制造真实故障信号
让 Nginx 面对真正的后端不可用场景，才能触发 proxy_cache_use_stale 的降级逻辑：
- 临时关闭所有 upstream 服务，例如执行
systemctl stop your-app或kill -9对应进程 - 确保 Nginx 连不上后端：既不能建立 TCP 连接，也无法收到任何 HTTP 响应（包括 502/503）
- 避免用
iptables拦截端口或注入延迟——这类操作常只触发 timeout，而 timeout 不是宕机的可靠信号，容易误判瞬时抖动
从客户端视角验证三项硬指标
打开浏览器开发者工具或用 curl 发起多次请求，确认以下三点同时成立：
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
- 响应状态码仍是 200（或原始成功状态码），不是 502/503/504，也不返回 Nginx 默认错误页
- 响应头中包含 X-Cache: STALE（需提前配置
add_header X-Cache $upstream_cache_status;） - 响应体内容与故障前完全一致：文字、JSON 字段、HTML 结构、时间戳均未变化；不是空数据、不是“服务暂不可用”提示、也不是格式错乱的片段
压测并发下的容灾稳定性
单请求 OK 不代表高可用。用 wrk 模拟突发流量，检验锁与后台更新是否协同生效：
- 运行
wrk -t4 -c200 -d10s "http://your-domain.com/api/data" - 观察平均耗时是否稳定在几十毫秒（如 40–80ms），而非随并发飙升至秒级
- 检查 access.log 中
$upstream_cache_status字段：多数为 STALE，少量为 HIT（后台刷新成功后），极少出现 MISS 或 EXPIRED - 确认 error.log 中无大量 upstream timed out 或 connect() failed 报错——说明请求没有全部打向已宕机的后端
验证缓存内容是否真正“可用即用”
极端故障下，用户需要的是能打开、能阅读、能点击的页面，不是技术上“没报错”：
- 对 HTML 页面：标题、正文、导航栏能正常渲染；内联 JS 能加载执行（若已缓存或不依赖后端）
- 对 API 接口：返回完整 JSON，字段齐全、结构合法，前端可直接解析使用，不因字段缺失导致白屏或报错
- 避免返回半截响应、截断的 JSON、或含动态时间戳导致前后不一致的内容
