最真实有效的测试方式是直接停掉上游服务，观察客户端是否持续获得200响应、X-Cache: STALE头及内容一致的可用结果，同时压测验证STALE占比高、耗时稳定且无大量后端错误。
直接模拟后端不可用并观察客户端实际响应，是最真实有效的测试方式。重点不是看 Nginx 日志或状态码是否“看起来正常”，而是确认用户能否在抖动中持续拿到可读、一致、低延迟的内容。
停掉上游服务，制造真实故障信号
这是验证容灾能力的基准操作：
- 临时关闭所有 upstream server（如 systemctl stop your-app 或 kill -9 对应进程）
- 确保 Nginx 不再能建立连接或收到任何有效响应——此时会触发 error、http_502/503/504 等 proxy_cache_use_stale 的合法触发条件
- 避免用 iptables 拦截端口或 mock 延迟：它们可能只触发 timeout，而 timeout 不推荐作为 stale 主要依据（易误判瞬时抖动）
从客户端视角验证三项硬指标
打开浏览器开发者工具或用 curl，发起多次请求，检查以下内容是否同时满足：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 响应状态码仍是 200（或原始成功码），不是 502/503/504；Nginx 未返回默认错误页
- 响应头含 X-Cache: STALE（需提前配置 add_header X-Cache $upstream_cache_status;）
- 响应体内容与故障前完全一致：文字、结构、JSON 字段、时间戳都未变；不是空数据、不是“服务暂不可用”提示、也不是格式错乱的片段
压测并发穿透场景，检验锁与后台更新协同效果
单请求 OK 不代表高可用。用 wrk 或 ab 模拟突发流量：
- 执行 wrk -t4 -c200 -d10s "http://your-domain.com/api/data"
- 观察响应耗时是否稳定在几十毫秒（如 40–80ms），而非随并发飙升到秒级
- 检查 access.log 中 $upstream_cache_status 字段：多数应为 STALE，少量为 HIT（后台刷新成功后），极少出现 MISS 或 EXPIRED（说明 proxy_cache_lock + proxy_cache_lock_timeout 生效）
- 确认 error.log 中无大量 upstream timed out 或 connect() failed 报错——说明请求未全部打向宕机后端
验证缓存内容是否真正“可用即用”
极端抖动下，用户需要的是“能打开、能阅读、能点击”的页面，而非技术上“没报错”：
- 对 HTML 页面，打开后能正常渲染标题、正文、导航栏；JavaScript 能加载执行（若内联或已缓存）
- 对 API 接口，返回的 JSON 包含完整字段和合理值（如 status: "success", data: [...]），不是 null 或空数组
- 若页面含动态时间（如 “最后更新：2026-10-08 14:22”），允许它陈旧，但不能变成 “NaN” 或报错
