当缓存资源过期时，Cloudflare 使用 Cache-Control 中的 stale-while-revalidate 指令来确定是否可以在从源站获取新副本的同时继续提供 stale 资源。如果指令存在且资源在允许的 staleness 窗口内，Cloudflare 向访客提供过期内容并在后台重新验证。通过使用 If-Modified-Since 和 ETag 等标头，Cloudflare 验证内容而无需完全重新获取，减少源站流量。
重新验证完全异步。当缓存资源过期且设置了 stale-while-revalidate 时，过期后到达的第一个请求在后台触发重新验证。该请求立即接收 stale 内容和 UPDATING 状态，而非阻塞等待源站响应。所有后续请求也接收 stale 内容和 UPDATING 状态，直到源站响应。重新验证完成后，后续请求接收 fresh 内容和 HIT 状态。
如果 stale 内容仍然有效，Cloudflare 设置新的 TTL。如果内容已更改，源站提供 fresh 内容替换旧内容。
Cloudflare 仅在源站在其 Cache-Control 标头中包含 stale-while-revalidate 指令时，在重新验证期间提供 stale 内容。没有此指令，访客在接收内容之前等待源站响应。
如果源站设置了 stale-while-revalidate 但您想覆盖它，可以通过 Cache Rules 中的 Serve stale content while revalidating 设置禁用 stale 提供。
启用 Origin Cache Control 时，以下 Cache-Control 指令阻止 Cloudflare 提供 stale 内容，依据 RFC 9111 §4.2.4 ↗：
must-revalidate— 禁止提供 stale 内容；缓存必须先与源站重新验证。proxy-revalidate— 与must-revalidate相同，但仅适用于共享缓存（如 Cloudflare）。s-maxage— 隐含proxy-revalidate语义，因此共享缓存不能提供 stale 内容。no-cache— 在提供任何缓存响应之前需要重新验证。
如果任何这些指令与 stale-while-revalidate 同时存在，Cloudflare 不会提供 stale 内容——请求将返回 EXPIRED 而非 UPDATING。
有关所有可用指令或禁用 Origin Cache Control 时的行为，请参阅 Cache-Control directives。
当源站服务器响应中缺少 Last-Modified ↗ 和 Etag ↗ 标头时，Smart Edge Revalidation 将对象在 Cloudflare 全球网络上缓存的时间用作 Last-Modified 标头值。当浏览器使用 If-Modified-Since 或 If-None-Match 向 Cloudflare 发送重新验证请求时，我们的全球网络可以使用 Smart Edge Revalidation 生成的 Last-Modified 标头回答这些重新验证问题。这样，即使源站未发送这些标头，我们的全球网络也能确保高效重新验证。