应检查 proxy_cache_use_stale 是否误配导致返回陈旧数据，重点排查 error/timeout 触发条件过宽、proxy_read_timeout 过短、proxy_cache_lock 配置不当及后端真实状态被误判等问题。
排查 proxy_cache_use_stale 导致返回陈旧数据的问题，核心是确认 Nginx 是否在不该用 stale 时用了它——即后端实际可用或响应正常，但 Nginx 却返回了缓存的旧内容。
检查是否触发了 stale 条件
该指令只有在后端出现特定异常时才启用陈旧缓存。常见被误配的情况是把 updating、http_500 等条件写得过于宽泛，或未结合 proxy_cache_lock 使用，导致并发请求中多个请求同时回源失败后，Nginx 优先返回 stale 而非等待更新。
- 查看当前配置中启用了哪些 stale 触发项，例如：
proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504; - 重点排查
error和timeout：如果上游网络偶发抖动或超时设置过短（如proxy_read_timeout 1;），就容易频繁触发 stale。 - 用
curl -I或浏览器开发者工具看响应头，若返回内容带有X-Cache: HIT from stale（需你自定义日志或 header）或Age值远大于预期，说明确实走了 stale 流程。
验证后端真实状态是否被误判
Nginx 判断“后端不可用”依赖的是连接阶段、发送请求阶段、读取响应头阶段的错误，不校验响应体内容。即使后端返回了 200，但 body 是空或格式错误，Nginx 仍可能因超时/断连认为失败。
WebChat Voice Proxy
下载
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
- 用
tcpdump或strace抓包，确认 Nginx 与 upstream 之间是否真有连接重置、RST、超时等； - 临时关闭
proxy_cache_use_stale（设为off），观察问题是否消失——若消失，基本锁定是该指令误触发； - 检查 upstream 是否存在慢响应：比如某接口平均耗时 900ms，而你设置了
proxy_read_timeout 1s，加上网络毛刺，就可能被判定为 timeout 并走 stale。
确认缓存 key 和过期逻辑是否干扰判断
陈旧数据能否返回，还受 proxy_cache_valid 和 proxy_cache_lock 影响。若缓存尚未过期，Nginx 默认不会进入 stale 流程；但若开启 proxy_cache_lock，且 lock 超时（proxy_cache_lock_timeout），也可能退回到 stale。
- 检查
proxy_cache_valid是否对关键状态码（如 200）设置了较长有效期（如proxy_cache_valid 200 1h;），导致即使后端已更新，缓存仍“新鲜”，stale 不会被考虑； - 若启用了
proxy_cache_lock，务必同步设置合理的proxy_cache_lock_timeout（建议 ≥ 后端 P95 响应时间），否则 lock 失败会直接 fallback 到 stale； - 确保
proxy_cache_key没有遗漏影响缓存区分的变量（如忽略$args或$cookie_user），否则不同用户的请求可能共用同一 stale 缓存。
通过日志定位具体触发路径
Nginx 默认不记录为何使用 stale，需主动增强日志输出：
- 在
log_format中加入$upstream_cache_status（值为STALE表示走了陈旧缓存）； - 添加
$upstream_http_x_cache或自定义 header（如 upstream 返回X-Cache-Status: UPDATING）辅助判断后端意图； - 开启
error_log ... debug;（仅临时），搜索关键字cache use stale或upstream timed out，可精准看到哪类错误触发了 stale。
