Origin Cache Control 是 Cloudflare 的一项功能。在 Enterprise 客户的网站上启用时，表示 Cloudflare 应严格遵循从源站服务器收到的 Cache-Control 指令。Free、Pro 和 Business 客户默认启用此功能。
源站服务器 HTTP 响应中的 Cache-Control 指令向 Cloudflare 等中间服务提供特定的缓存指令 ↗。
启用 Origin Cache Control 功能后，将按指定遵循源站服务器响应中存在的 Cache-Control 指令。例如，如果响应包含 3,600 秒的 max-age 指令，Cloudflare 将在再次检查源站服务器更新之前缓存该资源那么长时间。
Cloudflare 的 Cache Rules 允许用户增强或覆盖源站服务器的 Cache-Control 标头或 Cloudflare 设置的默认策略。
以下部分涵盖：
- 最常见的
Cache-Control指令。 - 如何启用 Origin Cache Control。
- 启用 Origin Cache Control 时的行为。
- 其他 Cloudflare 产品如何与
Cache-Control指令交互。
Cache-Control 标头可以包含多个指令，指令决定了谁可以缓存资源以及这些资源在需要更新之前可以缓存多长时间。
如果多个指令一起传递，每个指令用逗号分隔。如果指令需要参数，参数跟在指令后面，用等号分隔。例如：max-age=86400。
可缓存性是指资源是否应进入缓存，以下指令表示资源的可缓存性。
public— 表示任何缓存都可以存储响应，即使响应通常不可缓存或仅可在私有缓存中缓存。private— 表示响应消息针对单个用户（如浏览器缓存），不得由 Cloudflare 或企业代理等共享缓存存储。no-store— 表示任何缓存（如客户端或代理缓存）都不得存储即时请求或响应的任何部分。
过期是指资源应在缓存中保留多长时间，以下指令影响资源在缓存中的保留时间。
max-age=seconds— 表示响应的过期时间为其 age 大于指定秒数之后。Age 定义为自资源从源站服务器提供以来的秒数。seconds参数是一个不带引号的整数。s-maxage=seconds— 表示在共享缓存中，此指令指定的最大 age 覆盖max-age指令或Expires标头字段指定的最大 age。s-maxage指令还隐含了proxy-revalidate响应指令的语义。浏览器会忽略s-maxage。
no-cache— 表示响应不能在源站服务器成功验证之前用于满足后续请求。这允许源站服务器阻止缓存在不联系源站的情况下使用其来满足请求，即使是配置为发送过期响应的缓存也是如此。
确保源站服务器中的 HTTP Expires 标头设置为格林威治标准时间 (GMT)，如 RFC 2616 ↗ 所规定。
重新验证决定了缓存在资源过期时的行为，以下指令影响重新验证行为。
must-revalidate— 表示一旦资源过期，缓存（客户端或代理）必须在源站服务器成功验证之前不得使用该响应满足后续请求。proxy-revalidate— 与must-revalidate响应指令含义相同，但不适用于私有客户端缓存。stale-while-revalidate=<seconds>— 出现在 HTTP 响应中时，表示缓存可以在资源过期后继续提供该响应，最长可延长到资源过期后指定的秒数。如果启用了 Always Online，则stale-while-revalidate和stale-if-error指令会被忽略。使用 Cache API 方法cache.match或cache.put时不支持此指令。有关更多信息，请参阅 Workers 的 Cache API 文档。
stale-if-error=<seconds>— 表示遇到错误时，可以使用缓存的过期响应来满足请求，无论其他新鲜度信息如何。要避免此行为，请在从源站返回的对象中包含stale-if-error=0指令。使用 Cache API 方法cache.match或cache.put时不支持此指令。有关更多信息，请参阅 Workers 的 Cache API 文档。
如果启用了 Always Online 或传递了明确的协议内指令，则忽略 stale-if-error 指令。明确的协议内指令示例包括 no-store 或 no-cache cache 指令、must-revalidate 缓存响应指令，或适用的 s-maxage 或 proxy-revalidate 缓存响应指令。
下面列出了影响缓存行为的其他指令。
no-transform— 表示中间件（无论是否实现缓存）不得转换有效负载。vary— 默认情况下，Cloudflare 在缓存决策中不考虑 vary 值。配置 Cache Rules Vary 设置 时、配置 Vary for images 时，以及 vary 标头为vary: accept-encoding时，会遵循 vary 值。immutable— 向客户端表示响应正文不会随时间变化。如果资源未过期，则服务器上的资源是不变的。用户不应发送条件重新验证请求（如If-None-Match或If-Modified-Since）来检查更新，即使用户明确刷新页面也是如此。此指令对 Cloudflare 等公共缓存没有影响，但会改变浏览器行为。
关于 Cache-Control: no-store 和 Cache-Control: no-cache 指令之间经常存在混淆，特别是它们如何影响浏览器缓存和 Back-Forward Cache ↗（BFCache）等功能。
- 告知浏览器和中间件（如 CDN）在任何情况下都不存储响应的副本。
- 响应永远不会写入磁盘或内存，这意味着浏览器每次都必须重新获取它。
- 在许多浏览器中，
no-store会禁用 BFCache，因为从 BFCache 恢复页面需要浏览器保留页面内存状态的副本，这与"不存储"指令相悖。 - 此指令用于高度敏感或动态的数据（例如，银行应用程序、个人信息、安全仪表板）。
- 允许存储响应（在浏览器和中间缓存中），但在使用之前需要与源站服务器重新验证。
- 这确保内容始终是最新的，同时仍然允许 BFCache 或其他形式的性能优化。
- 此指令用于频繁变化但不敏感的数据，通过验证而不是重新下载可以更快地提供。
有关这些指令在启用或禁用 Origin Cache Control 时的行为，请参阅 Directives 部分。
如果您启用 Origin Cache Control，Cloudflare 将严格遵循 RFC 7234 ↗。Enterprise 客户可以选择 Cloudflare 是否遵循此行为，通过仪表板中的缓存规则或 API 为其网站启用或禁用 Origin Cache Control。Free、Pro 和 Business 客户默认启用此选项且无法禁用。
以下部分涵盖与启用或禁用 Origin Cache Control 相关的指令和行为条件。
下表列出了禁用和启用 Origin Cache Control 时指令的行为。
| 指令 | 禁用 Origin Cache Control 时的行为 | 启用 Origin Cache Control 时的行为 |
|---|---|---|
s-maxage=0 |
不缓存。 | 缓存并始终重新验证。 |
max-age=0 |
不缓存。 | 缓存并始终重新验证。 |
no-cache |
不缓存。 | 缓存并始终重新验证，不提供过期内容。 |
no-cache=<headers> |
不缓存。 | 如果 no-cache=<headers> 中提到的标头不存在则缓存；如果存在任何提到的标头则始终重新验证。 |
Private=<headers> |
不缓存。 | 不缓存 Private=<headers> 指令中提到的 <headers> 值。 |
must-revalidate |
缓存指令被忽略，提供过期内容。 | 不提供过期内容，CDN 和浏览器都必须重新验证。 |
proxy-revalidate |
缓存指令被忽略，提供过期内容。 | 不提供过期内容，CDN 必须重新验证但浏览器不需要。 |
no-transform |
可能进行（解）压缩、Polish、邮件过滤等处理。 | 不转换正文。 |
s-maxage=delta, delta>1 |
与 max-age 相同。 |
max-age 和 proxy-revalidate。 |
immutable |
不向下游代理。 | 向下游代理，面向浏览器，不影响缓存代理。 |
no-store |
不缓存。 | 不缓存。 |
某些场景在启用或禁用 Origin Cache Control 时也会影响其行为。
条件 | 禁用 Origin Cache Control 时的行为 | 启用 Origin Cache Control 时的行为 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
存在 | 内容可能被缓存。 | 仅在同时存在 | ||||||||||||
使用 | 日志中显示 | 日志中显示 | ||||||||||||
源站响应有 | 内容可能以剥离 | 内容不缓存。 | ||||||||||||
设置了 Browser Cache TTL。 | 返回给用户的 | 如果源站在 |
查看以下示例，了解使用 Cache-Control 标头控制特定缓存行为时应使用哪些指令。
缓存静态资源。
Cache-Control: public, max-age=86400
确保机密资源永不被缓存。
Cache-Control: no-store
在浏览器上缓存资源，但不在代理缓存上缓存。
Cache-Control: private, max-age=3600
在客户端和代理缓存中缓存资源，但提供时优先重新验证。
Cache-Control: public, no-cache
在代理缓存中缓存资源，但提供时要求代理必须重新验证。
Cache-Control: public, no-cache, proxy-revalidate 或 Cache-Control: public, s-maxage=0
在代理缓存中缓存资源，但提供时要求任何缓存都必须重新验证。
Cache-Control: public, no-cache, must-revalidate
缓存资源，但确保代理不会对其进行转换。
Cache-Control: public, no-transform
此配置还会禁用从我们的边缘到访问者的 gzip 或 brotli 压缩转换（如果原始负载以未压缩方式提供）。
缓存资源并重新验证，但在源站服务器不可达时允许提供过期响应。
Cache-Control: public, max-age=3600, stale-if-error=60
通过此配置，Cloudflare 在资源缓存 3600 秒（一小时）后尝试与源站服务器重新验证内容。如果服务器返回错误而非正确的重新验证响应，Cloudflare 将在资源过期后继续提供过期资源，最长延续一分钟。
在 Cloudflare 和访问者浏览器上缓存不同时长的资源。
Cache-Control: public, max-age=7200, s-maxage=3600
缓存资源并在资源重新验证期间继续提供。
Cache-Control: max-age=600, stale-while-revalidate=30
此配置表示资源在 600 秒内是新鲜的。资源可以在过期后额外提供最多 30 秒的过期内容，同时 Cloudflare 在后台与源站重新验证该资源。有关更多信息，请参阅 Revalidation。
本节介绍其他 Cloudflare 功能如何与 Cache-Control 指令交互。
Edge Cache TTL 缓存规则会覆盖 s-maxage 并在存在时禁用重新验证指令。当 Cloudflare 启用 Origin Cache Control 时，原始 Cache-Control 标头会从边缘向下游传递，即使存在 Edge Cache TTL 覆盖也是如此。否则，当 Cloudflare 禁用 Origin Cache Control 时，Cloudflare 将覆盖 Origin Cache Control。
Browser Cache TTL 缓存规则会覆盖从边缘向下游传递的 max-age 设置，通常传递到访问者的浏览器。
当存在 no-transform 指令时，Polish 会被禁用。
当存在 no-transform 指令时，压缩会被禁用。如果从源站获取的原始资源是压缩的，则以压缩方式提供给访问者。如果原始资源未压缩，则不应用压缩。
当存在 no-transform 指令时，JavaScript 检测注入会被禁用。受影响请求的 cf.bot_management.js_detection.passed 字段将显示为 missing。