源站故障时是否继续返回旧缓存：stale-if-error的适用边界

源站故障时，继续显示昨天的公开帮助文档可能比完全打不开更有用；但继续展示已经撤销的下载权限，后果就不同。CDN是否返回旧缓存，应由内容的业务含义决定，不能全站套用“可用性优先”。

两种旧缓存机制解决不同问题

RFC 5861描述了stale-if-error与stale-while-revalidate：前者允许在符合条件的错误出现时使用陈旧响应，后者允许在后台重新验证时先提供陈旧响应。两者均需要实际缓存实现支持，响应头存在不等于行为一定生效。

这里讨论的是已经允许被该缓存保存的内容。不能借故障兜底绕过私有内容的存储和权限边界，也不能把旧响应无限期视为正确结果。

先列业务容忍表

这是讨论模板，不是推荐给所有网站的默认配置。业务负责人应为允许陈旧的对象确定最大可接受时间，并说明超过这个时间该显示什么。

错误条件需要实际验证

测试时区分连接失败、超时、服务端错误以及正常返回的空数据。后端返回一个200错误页面，缓存未必会把它视为故障；应用把“查不到库存”伪装成正常结果，也不能由CDN自动判断含义。

在隔离或明确授权的测试路径上模拟条件，记录原缓存的版本、生成时间、有效期和故障开始时间。检查命中旧内容时是否有可观察标识，超过允许窗口后是否按设计停止兜底。不要直接中断生产源站来验证一个尚未确认支持的功能。

故障恢复同样需要一个阶段

源站恢复后，确认新内容能够重新进入正常服务路径，并观察回源压力。此前被旧缓存遮住的错误，可能在缓存集中失效后再次出现。监控应同时看用户成功率和源站状态，不能因页面仍可打开而取消告警。

紧急撤回场景要另行准备：例如公开文件含有错误信息，需要确认删除、刷新和故障兜底规则如何相互作用。保留旧对象作为可用性措施之前，应先确认它不会让撤回失去意义。

采购和交接时问清楚什么

向SCDN服务商确认支持的响应头、错误类型、最长保留范围和观察方式。若产品不支持这类机制，可以考虑应用维护页或经审核的静态说明，但应清楚标示状态，不能制造交易成功的假象。

最终交付的是内容范围、陈旧上限、恢复动作和撤回路径四项记录。遇到“外网仍是旧版”的现象，可结合多层缓存排查判断这究竟是预期兜底，还是更新链路出了问题。

资料核对日期：2026年10月30日。本文由AI辅助整理，技术事实依据文内原始资料核对。示例与操作清单供实施参考；产品配置和软件维护状态以实施时的官方资料为准。