刷新和预热资源

资源刷新

刷新操作的本质是向边缘节点下发缓存失效指令，而非直接删除文件。边缘节点收到指令后，会将匹配的缓存资源标记为"失效"或"过期"。当用户再次请求该资源时，边缘节点发现缓存已失效，便会回源获取最新资源，并在返回给用户的同时重新缓存。

控制台默认刷新方式说明：在CDN控制台执行目录刷新或正则刷新时，默认采用标记刷新方式。标记刷新仅标记缓存过期，当边缘节点回源时，会携带If-Modified-Since或If-None-Match请求头。若源站返回304 Not Modified，边缘节点将保留旧缓存副本。这种方式可节省回源流量，但在某些场景下（如源站同名更新、违规内容清理、配置变更后）可能导致用户仍访问到旧内容。若需彻底清除缓存，建议使用API调用刷新缓存接口，并将Force参数设置为true进行强制刷新。

适用场景

• 资源更新和发布：源站的旧资源更新或升级后，为避免用户仍访问到旧的缓存资源，可提交对应资源的URL或目录进行刷新，确保用户访问到最新的资源并缓存至边缘节点。

• 违规资源清理：源站存在不合规内容时，删除源站资源后，由于边缘节点仍可能存在缓存，资源仍可能被访问到。此时可通过URL刷新功能更新缓存资源，确保违规内容及时清除。

资源预热

预热操作由边缘节点根据提交的URL列表，主动向源站发起请求，将资源缓存到边缘节点上，而非源站主动推送。预热可提升新资源或活动页面的首次访问速度，同时减少活动上线时的回源压力，保护源站。

预热机制说明：预热操作默认将资源缓存至L2回源节点（二级缓存层），而非直接分发至所有L1边缘节点。当用户首次访问某资源时，L1边缘节点会从L2回源节点或源站拉取内容并缓存。因此，预热操作主要解决的是降低源站压力的问题，L1边缘节点的全面缓存覆盖依赖于用户的实际访问分布。只有当用户实际访问某L1节点后，该节点完成本地缓存，后续同区域用户才能直接从L1命中缓存获得加速。

适用场景

• 首次接入CDN：首次接入CDN后，可将热点静态资源提前预热至边缘节点。用户访问时可直接由边缘节点响应，避免初次访问速度慢的问题，提升用户体验。

• 运营活动：运营大型活动时，提前将活动页涉及的静态资源预热至边缘节点。活动开始后，用户访问的所有静态资源均已缓存至边缘节点，由边缘节点直接响应，确保活动页面快速加载。

• 安装包或其他大文件发布：新版本安装包或升级包发布前，提前将资源预热至边缘节点。产品正式上线后，用户的下载请求将直接由边缘节点响应，提升下载速度，降低源站压力。

缓存层级与效果

预热操作主要将资源缓存至 L2 汇聚节点，而非所有 L1 边缘节点。用户首次访问时，L1 边缘节点会从 L2 节点或源站拉取资源。因此，预热的主要目的是降低源站压力，而非保证所有 L1 边缘节点立即命中缓存。

• 效果评估：预热有助于提升缓存命中率，但对于小文件或非热点文件，建议合理评估预热成本。预热会产生回源流量，大致等于单个文件大小乘以 L2 节点数量。

刷新资源

1. 登录CDN控制台。

2. 在左侧导航栏，单击刷新预热。

3. 在刷新缓存/预热缓存页签，选择操作类型为刷新。

4. 根据需求选择刷新方式并提交任务。

如何实现全站刷新（全局/根目录刷新）

CDN 不支持一键全站刷新，但您可以通过以下方式实现全站刷新：

1. 目录刷新：在操作方式中选择目录，输入域名根目录 URL（如 https://www.example.com/）。URL 必须以 / 结尾。

2. 强制刷新（API）：若目录刷新后部分节点仍返回旧缓存，建议调用刷新缓存 API（RefreshObjectCaches），将 Force 参数设置为 true 进行强制刷新。强制刷新将无条件删除节点上的缓存资源，确保下次访问回源获取最新内容。

   说明

   控制台的刷新表单不支持设置 Force 参数，如需使用强制刷新，请通过 API 或 SDK 调用。

3. 单击提交，系统开始执行刷新任务。

   • 刷新任务一旦提交成功，无法中止。

   • 刷新任务通常需要 5~6 分钟在全网生效。如果缓存过期时间小于此值，则无需手动刷新。

   • 如果在OSS控制台开启了CDN缓存自动刷新，则无法通过 CDN 控制台查看 OSS 的缓存自动刷新任务。

预热资源

1. 登录CDN控制台。

2. 在左侧导航栏，单击刷新预热。

3. 在刷新缓存/预热缓存页签，选择操作类型为预热。

4. 预热内容输入框内输入需要预热的完整文件 URL，每行一个。不支持预热目录。例如：https://www.example.com/install/package.zip。

5. 单击提交，系统开始执行预热任务。

   • 预热任务一旦提交成功，无法中止。

   • 预热任务的完成时间取决于文件大小、数量和源站性能，通常需要 5~30 分钟。

预热 OSS 文件注意事项

当源站为 OSS 时，预热 URL 须注意以下规范：

• URL 格式：必须填写 CDN 加速域名的完整 URL（如 https://cdn.example.com/path/file.zip），不能填写源站 OSS 的内网或外网地址（如 https://examplebucket.oss-cn-hangzhou.aliyuncs.com/...）。

• 签名参数：预热 URL 中不得包含 OSS 的临时签名参数（如 Expires、OSSAccessKeyId、Signature 等）。这些是临时授权参数，会导致预热失败。请使用不含签名的永久可访问 URL。

• 源站响应状态码：预热要求源站返回 200 状态码。若源站返回 308 重定向或其他非 200 状态码，预热任务将失败。例如，URL 末尾缺少斜杠导致 OSS 返回重定向时，应补全斜杠后重新提交。

自动化刷新或预热

存在以下情况时，建议使用自动化脚本刷新和预热：

• 无开发人员，需手动提交刷新预热任务，运维成本高。

• 刷新或预热URL过多，分批提交导致效率低。

• 需要人工或程序判断刷新预热任务是否正常进行。

标记刷新（CDN默认策略）

• 适用场景：常规内容更新，如发布新版静态文件。

• 机制：这是目录刷新和正则刷新在控制台上的默认行为。CDN 边缘节点在回源时，会携带If-Modified-Since或If-None-Match请求头。源站会根据这些头信息判断资源是否已更新。

• 效果：如果源站资源未变更，源站将返回304 Not Modified状态码，CDN 边缘节点会继续使用旧的缓存副本，不会消耗回源流量。这是一种节省成本和源站资源的优化方式。若需彻底清除缓存（如违规清理、配置变更、同名文件更新），标记刷新可能无法满足需求，请使用强制刷新。

强制刷新

• 适用场景：紧急清理违规或错误资源、修复错误的Cache-Control响应头配置后需要强制全网更新、源站文件同名更新等场景。

• 机制：通过刷新缓存提交刷新任务时，将参数Force设置为true来触发。此模式下，CDN 边缘节点会无条件地将缓存资源标记为失效，不再进行304校验。

• 效果：下次访问该资源时，CDN 边缘节点将必须回源获取新版本，即使源站上的文件并未改变。

强制刷新的典型应用场景

以下场景建议使用强制刷新（通过刷新缓存 API设置 Force=true）：

• 违规内容或木马清理：源站删除恶意文件后，必须使用强制刷新，或确保源站对该 URL 返回正确的 HTTP 状态码（如 404）。否则边缘节点可能因标记刷新回源校验后仍保留旧缓存，继续提供违规内容。

• 同名文件更新（配置变更）：若源站文件同名替换但内容不同，标记刷新可能因源站返回 304 Not Modified 状态码而继续使用旧缓存。此时应使用强制刷新确保全网更新到最新内容。

• 页面显示异常或首页循环：若访问网站其他页面时一直显示首页，或图片显示异常，且 URL 刷新无效，建议使用目录刷新并通过 API 设置 Force=true 进行强制刷新。

API 强制刷新参数示例：

{
  "ObjectType": "Directory",
  "ObjectPath": "https://www.example.com/static/",
  "Force": true
}

关键参数说明：

• ObjectType：填写Directory（目录）或File（文件）。

• ObjectPath：填写以/结尾的完整目录路径，或具体的文件URL。

• Force：设置为true开启强制刷新，忽略源站的If-Modified-Since/If-None-Match校验，直接清除缓存。