上游已恢复却持续收到旧失败，怎样核对代理是否缓存了错误响应

上游已经恢复，用户仍收到旧失败，不一定是上游再次故障，也可能命中了显式配置过的错误响应缓存。本文只讨论人为启用的实验缓存契约，不暗示Nginx默认会缓存所有错误。当前运行的是离线时间线，未执行Nginx或真实HTTP缓存。

用先失败后成功的假序列隔离缓存影响

三个请求发生在零、一百、二千一百毫秒，假上游第一次返回503，以后返回200。参考错误缓存TTL两千毫秒。允许缓存503时，第二次仍命中旧失败，结果序列503、503、200，上游只收到两次；不缓存503时，第二次就访问已恢复的上游，结果503、200、200。

第三条参考路径在第二次前显式失效，同样得到503、200、200。这个失效是参考器清除自己的条目，不代表任意Nginx发行版都提供相同purge接口。附件配置片段只展示显式proxy_cache_valid 503 2s的实验意图，完整可用配置、响应头和缓存条件还需目标环境验证。

不要只看状态码判断缓存命中

两次503可能一次来自上游、一次来自缓存，也可能上游确实再次失败。验收应保存匿名缓存键、命中标记、条目年龄与上游调用计数，才能区分。测试用固定无敏感GET路径即可，不要为验证缓存而把真实鉴权生成接口纳入公共共享缓存。

HTTP缓存是否可存储还受请求方法、响应头、授权条件和显式配置等约束。RFC 9111与Nginx官方代理文档应一起核对，不能只从某一条cache_valid就推出整个生产链路行为。若还启用了stale使用策略或后台更新，旧结果可能有额外路径，需要单独设计时序，不应把它们悄悄混入这个两秒例子。

将恢复时刻与旧条目到期分开记录

本例上游在第一次之后就能成功，但缓存直到两秒到期，说明“源已恢复”与“用户看到恢复”存在不同时间轴。短TTL、禁用指定错误存储与受控失效，都是可以比较的策略；它们对流量和恢复可见时间的影响不同，不能只凭一次快恢复就决定所有错误都缓存或都不缓存。

本批结果reference_upstream_calls仅属于内存模型，没有实际命中日志。若补做本地集成，应使用独立假上游和隔离缓存目录，保存完整配置与版本，切勿直接删除Docker或生产代理管理的文件。验收的重点是确认自己到底显式缓存了哪些状态、多久以及怎样失效，而不是把看到的旧503自动归咎于模型服务。

配套样本与复核入口

下载本篇独立合成输入和实验运行器。上述文件放在同一目录后运行 python run_lab.py C040。完整运行需要全部四十四份输入及相关配置。结果中的method区分离线计算、静态参考检查与回环实测，不能把前两者当成真实网关已通过。

补充文件：c040.conf。合成表供独立复算，配置片段是否实跑以正文说明为准。

资料核对日期：2026-10-24。官方依据1；官方依据2。

与本站相关基础教程的区别：旧文侧重应用内容缓存；本文仅在显式启用的HTTP代理缓存中测试错误状态的存储与失效，不与C039租户缓存键设计重复。