Introducing Cache Response Rules

介绍缓存响应规则 | Cloudflare 博客

post

CDN

优化

产品新闻

应用服务

缓存

缓存规则

2026年7月23日

介绍缓存响应规则

Alex Krivit 和 Anthony Turcios

12分钟阅读

复制链接

今天，我们激动地宣布推出缓存响应规则。这是一种新的规则类型，它在源站服务器响应后、Cloudflare 缓存内容前执行。

如果你曾经因为某些本应轻松从缓存中获取的内容，却因 Set-Cookie 或错误的 Cache-Control 等头字段被强制重新拉取源站，而感到困扰，那么缓存响应规则就是为此而生。这些规则能够精准地在恰当的时机修正这些问题。

缓存决策的时机与方式

CDN 缓存与源站服务器协同工作。它们的目标是尽可能从缓存中响应请求，仅在边缘节点无法响应时才回源。每个缓存命中率的提升都源于对这种分工的精准把控。如果在不该检查缓存时检查，就会浪费本应失败的查询；如果检查频率过低，边缘节点本应吸收的流量会转而由源站处理，导致性能优势消失。

关键在于，源站决定了缓存的行为。当源站返回可缓存资源时，其响应头会告诉 Cloudflare 可以缓存多长时间、何时以及如何重新验证，甚至是否需要缓存。缓存的效率永远受限于源站的设置。如果源站配置错误，缓存将变得无关紧要，而源站基础设施成本却会急剧上升。

大多数缓存资格问题并非在请求阶段决定，而是在源站响应后才显现。

一位访客请求 /static/app.js。Cloudflare 检查缓存未命中，将请求转发至源站。源站返回文件后，响应头中悄然包含了一个 Set-Cookie 头。本应在所有 Cloudflare 数据中心缓存的资源，现在变得无法缓存。如果每个访客、每个网站都因相同意外头字段导致此问题，缓存命中率将浪费源站带宽、破坏性能并推高基础设施成本。

此类问题存在许多变体。源站对本可在 CDN 上安全缓存的资源返回 Cache-Control: no-cache。源站发送了正确的指令，但这些指令是为浏览器设计的，而非 Cloudflare。或者源站附加了一个过于激进的 ETag（特定资源版本的标识符），导致每个条件请求都触发重新验证冲突。尤其在大型团队中，负责源站响应的团队与管理 CDN 的团队往往不同。这使得修改一个简单头字段可能需要数周的协商。

这些问题都无法在请求阶段解决。当 Cloudflare 在 /app.js 的响应中看到 Set-Cookie 时，请求阶段早已结束。响应正在传输中。

因此，我们选择在正确的位置进行修复。

缓存响应规则在源站响应到达 Cloudflare 后、写入缓存前执行。通过它们，你可以重写 Cache-Control 指令、管理缓存标签，并在 Cloudflare 缓存看到这些字段前，从源站响应中移除 Set-Cookie、ETag 和 Last-Modified 等头字段。修复方案完全位于 Cloudflare，无需任何源站代码更改。

缺失的拼图

如果你已经使用过 Cloudflare 一段时间，应该见证过缓存控制功能的演变过程。几年前，这些功能大多集中在页面规则（Page Rules）中，页面规则作为一个单一但功能繁杂的原始工具，将缓存、重定向、安全策略及其他十余种行为混合在一起，所有规则都会在请求时进行评估。后来我们对这些规则进行了拆分，使只有与特定行为相关的规则才会被评估，从而减少不必要的延迟，并允许在不同行为之间进行复杂的规则叠加。缓存规则（Cache Rules）成为专门用于缓存决策的规则类型，与 CDN-Cache-Control、Origin Cache Control、自定义缓存键及其他控制功能共同协作，这些功能为你提供了精确的配置方式，告诉 Cloudflare 哪些内容可以安全缓存、缓存时长以及缓存条件。

这些控制功能有一个共同点：它们都基于请求（request）进行操作。

虽然这可能看起来不太直观，但这是合理的。Cloudflare 需要做出的最重要的缓存决策是：是否应该在缓存中查找该内容？以及使用什么键进行查找？这个问题必须在 Cloudflare 与源站通信之前就得到答案。如果在应该返回“是”的情况下错误地返回了“否”，请求已经为源站往返耗时付出了代价，响应无法再将这部分延迟补偿回来。请求时规则通过当时唯一可用的信息（如 URL、请求文件的扩展名、请求头、地理位置、设备类型等）来回答这个问题。通过这些请求参数以及用于修改这些参数的规则，我们判断某些内容是否可能存在于缓存中，并在与源站通信前优先检查缓存。

但有些缓存决策无法基于请求做出。源站的 Cache-Control 指令（如 cache-control: max-age=3600）是 Cloudflare 从源站接收到的响应的一部分。状态码、ETag、Last-Modified 时间戳、Set-Cookie 以及源站选择的 cache-tag 格式等响应内容，都是源站传递给缓存的信息。这些信息在请求时规则运行时是无法获取的。

源站的响应是事实依据，因此如果某些需要在 Cloudflare 上修改的内容在请求时不可用，你之前只能通过以下三种变通方式处理：

• 修改源站。
• 编写一个 Worker 脚本重新获取并重写响应。
• 接受较低的缓存命中率。

这些方法都会消耗工程时间、增加延迟或产生成本。缓存响应规则（Cache Response Rules）为你提供了第四个选择：一个规则集，允许你在响应内容进入 Cloudflare 缓存前对其进行修改。

两个阶段，两个问题

理解缓存规则（Cache Rules）与新缓存响应规则（Cache Response Rules）之间差异最清晰的方式是将其视为两个阶段，每个阶段回答一个特定问题。

• 缓存规则在请求阶段运行，即在 Cloudflare 与源站通信之前。它们回答的问题是：基于当前请求，Cloudflare 是否应该缓存响应？以及使用什么缓存键？这是请求阶段通过缓存规则可以做出的三个决策：是否缓存（可缓存 vs 绕过缓存）、对象标识（缓存键及未来如何识别存储对象）以及缓存方式（边缘 TTL、浏览器 TTL、允许服务过期内容等）。所有这些问题必须在源站获取前通过请求中的信息解决。

• 缓存响应规则在响应阶段运行，源站响应后、响应写入 Cloudflare 缓存之前触发。缓存响应规则的作用是：源站已返回响应后，是否需要调整缓存策略？缓存响应规则可通过移除导致响应无法缓存的头部、修改源站控制缓存的指令（告诉 Cloudflare 是否以及如何缓存），或设置缓存标签（用于清除内容）来实现。当缓存规则与缓存响应规则发生冲突时，缓存响应规则具有最终决定权。

响应阶段无法完成请求阶段能实现的所有操作。它无法更改“缓存什么”，因为缓存键已固定。但可以调整 Cloudflare 是否缓存以及如何缓存，例如响应规则可设置 no-store 使可缓存对象变为不可缓存，或移除 Set-Cookie 使不可缓存内容变为可缓存。然而，缓存响应规则无法通过响应阶段使原本不符合缓存条件的请求变为可缓存，因为时机已过。

因此，缓存响应规则并未取代缓存规则。缓存规则决定请求阶段是否缓存、缓存什么以及如何缓存。而缓存响应规则在源站响应被 Cloudflare 接收（这一阶段此前并不存在）后，对“是否缓存”和“如何缓存”拥有最终决定权。

可实现的功能

当前缓存响应规则支持三种操作。

• 移除破坏缓存的头部

set_cache_settings 操作会在 Cloudflare 评估缓存前，从源站响应中移除 Set-Cookie、ETag 或 Last-Modified 等头部：

"action_parameters": {
  "strip_etags": true,
  "strip_set_cookie": true,
  "strip_last_modified": true
}

这是解决静态资源上附带 Set-Cookie 的解决方案。源站框架常会将会话 Cookie 添加到每个响应中（用于负载均衡等目的），包括用户不希望与会话关联的资源响应。在响应阶段移除 Set-Cookie 可使这些资源重新变为可缓存，无需源站、负载均衡器或上游组件做任何更改。

缓存响应规则还会对完全不符合缓存条件的响应生效。例如，当从动态响应中移除 Set-Cookie 时，无论对象是否被存储，规则都会触发。这使您即使在响应未被缓存时，仍可控制客户端看到的内容。您还可以移除 ETag 和 Last-Modified，这在源站配置错误导致缓存抖动时非常有用。但需注意权衡：同时移除 ETag 和 Last-Modified 会为该响应启用智能边缘重新验证（Smart Edge Revalidation）。如果缓存响应规则随后添加了新的验证器，Cloudflare 将不会为浏览器的条件请求启用智能边缘重新验证。

因此，即使在动态请求中，剥离和修改头部已成为 Cloudflare 上一种全新的强大模式，但进行这些更改时需注意额外配置。

• 管理缓存标签

set_cache_tags 允许您在响应中添加、删除或设置用于按标签清除的缓存标签。标签可以是静态的：

"action_parameters": {
  "operation": "set",
  "values": ["product-catalog", "storefront"]
}

也可以从响应头表达式中计算得出：

"action_parameters": {
  "operation": "add",
  "expression": "split(http.response.headers[\"Surrogate-Keys\"][0], \",\", 64)"
}

在 CDN 迁移过程中，第二种形式能发挥关键作用。如果之前的 CDN 使用类似 Surrogate-Keys 的头字段（以逗号作为分隔符）为响应附加代理键，你可以在响应阶段直接将它们转换为 Cloudflare 的 Cache-Tag 格式。

split() 函数的第三个参数是 limit：生成的数组元素数量最大值在 1 到 128 之间。请选择一个明显大于单个响应实际标签数量的值。若设置为 1，则会将整个头字段作为一个标签返回。一旦响应中存在标签，通过标签清除（purge-by-tag）功能即可直接使用（这里的“直接使用”意味着通常在全球范围内可在 150 毫秒内完成清除）。

• 修改 Cache-Control 指令

set_cache_control 是执行主要操作的指令。你可以设置或移除单个指令：

• 时效性指令：max-age、s-maxage、stale-if-error、stale-while-revalidate
• 限定性指令：private、no-cache（可选 header-name 限定符）
• 布尔指令：no-store、no-transform、must-revalidate、proxy-revalidate、must-understand、public、immutable

对于每个指令，你还可以设置 cloudflare_only: true，这个功能常常会让人感到意外：

"action_parameters": {
  "s-maxage": {
    "operation": "set",
    "value": 86400,
    "cloudflare_only": true
  }
}

当 cloudflare_only 为 true 时，该指令会影响 Cloudflare 如何缓存响应，但发送到浏览器的下游 Cache-Control 值将保持不变。这相当于在源站端通过 CDN-Cache-Control 实现的功能的响应阶段版本：在 Cloudflare 端缓存资源 24 小时，但告诉浏览器其他信息。区别在于你现在是通过 Cloudflare 控制台的规则界面实现的，而不是要求源站设置单独的头字段。

值得借鉴的示例

以下是一些我们认为能帮助你理解缓存响应规则强大功能的示例。尝试使用它们、进行修改，并与社区其他成员分享，看看如何通过缓存响应规则实现强大的缓存定制。更多示例请参阅文档。

从静态资源扩展中移除 Set-Cookie

Expression:  http.request.uri.path.extension in {"js" "css" "woff2" "woff" "ttf" "png" "jpg" "svg"}
Action:      set_cache_settings
            strip_set_cookie: true

为什么有效：最常见的“本应可缓存却不可缓存”的原因是源站的会话中间件为每个响应附加了 Set-Cookie。通过移除已知静态扩展的 Set-Cookie，可以无需更改源站即可使这些响应变为可缓存。

注意事项：仅对不需要 Cookie 的资源类型执行此操作。如果源站在这些 URL 上使用 Cookie 来驱动变体行为（虽然不常见但有可能），请选择性地移除或通过路径限制这些头字段的移除范围。

在 Cloudflare 中为静态资源设置长期缓存，在浏览器中设置短期缓存

Expression: http.request.uri.path.extension in {"js" "css" "woff2"}
Action:     set_cache_control
            s-maxage: set 2592000 (30 days), cloudflare_only=true
            immutable: set
            max-age: set 86400  (1 day), cloudflare_only=false

为什么有效：Cloudflare 会将资源缓存 30 天并从缓存中提供服务。浏览器看到 max-age=86400，会在一天后重新验证。你可以在不更改源站的情况下将两个缓存生命周期解耦。

注意事项：immutable 告诉浏览器即使进行显式刷新也不重新验证。仅与带版本号/哈希值的文件名配合使用。

在已知静态路径上覆盖 no-cache

Expression: starts_with(http.request.uri.path, "/static/") and http.response.code eq 200
Action:   set_cache_control
        no-cache: remove
        s-maxage: set 3600, cloudflare_only=true

为什么有效：框架默认有时会为每个响应附加 no-cache。如果您知道 /static/* 是可以安全缓存的内容，可以通过移除该指令并设置自己的 TTL（仅限 Cloudflare），而无需更改源站或任何下游缓存所看到的内容。

注意事项：要诚实地判断哪些内容实际上是静态的。如果 /static/ 有时用于提供用户特定内容，请通过扩展名、响应头信号或内容类型缩小匹配范围。

在 CDN 迁移期间翻译缓存标签

Expression: any(http.response.headers.names[*] == "Surrogate-Keys")
Action:   set_cache_tags
        operation: add
        expression: split(http.response.headers["Surrogate-Keys"][0], ",", 64)

为什么有效：许多 CDN 迁移的痛点来自于源站工具生成的缓存标签头使用了其他厂商的格式。无需要求源站团队发布添加 Cloudflare Cache-Tag 的版本，而是在响应阶段直接翻译现有头信息。Cloudflare 的按标签清除功能可以立即生效。

注意事项：split() 的第三个参数是限制（1–128）结果数组的大小，与分隔符无关。

如何使用缓存响应规则

仪表盘

• 前往 Cloudflare 仪表盘的缓存 > 缓存规则。

• 选择创建规则，然后选择缓存响应规则。

• 选择名称和表达式。表达式构建器同时暴露请求字段和响应字段。

• 选择操作：修改缓存控制指令、修改缓存标签或移除头信息。

• 对于指令，当您希望更改仅适用于 Cloudflare 的资产视图时，切换 Cloudflare 专用选项。

• 保存为草稿进行迭代，或直接部署。

API

此阶段的规则位于：

/zones/{zone_id}/rulesets/phases/http_response_cache_settings/entrypoint

有关如何使用缓存响应规则的更多信息，包括 API 和 Terraform 示例，请参阅文档。

今天就使用缓存响应规则

缓存规则看到了请求。缓存响应规则看到了响应。两者都为您提供更多控制权，以在 Cloudflare 上构建完美的缓存。它们在所有计划中均可使用 —— 前来尝试吧！

目录列

讨论列

相关标签和社交媒体链接

相关标签

关注社交媒体

• Cloudflare

• Alex Krivit

电子邮件订阅