通过刷新功能可删除CDN边缘节点上已缓存的资源，并强制边缘节点回源站获取最新资源，适用于源站资源更新和发布、违规资源清理、域名配置变更等场景；通过预热功能可在业务高峰前预先将热门资源缓存到边缘节点，降低源站压力。
功能介绍
资源刷新
刷新操作的本质是向边缘节点下发缓存失效指令，而非直接删除文件。边缘节点收到指令后，会将匹配的缓存资源标记为"失效"或"过期"。当用户再次请求该资源时，边缘节点发现缓存已失效，便会回源获取最新资源，并在返回给用户的同时重新缓存。
控制台默认刷新方式说明：在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后，可将热点静态资源提前预热至边缘节点。用户访问时可直接由边缘节点响应，避免初次访问速度慢的问题，提升用户体验。
运营活动：运营大型活动时，提前将活动页涉及的静态资源预热至边缘节点。活动开始后，用户访问的所有静态资源均已缓存至边缘节点，由边缘节点直接响应，确保活动页面快速加载。
安装包或其他大文件发布：新版本安装包或升级包发布前，提前将资源预热至边缘节点。产品正式上线后，用户的下载请求将直接由边缘节点响应，提升下载速度，降低源站压力。
前提条件
权限要求：使用 RAM 用户操作时，须先授予
cdn:PushObjectCache（预热）和cdn:RefreshObjectCaches（刷新）权限。详情请参见CDN自定义权限策略参考。URL 格式：提交的 URL 中若包含非 ASCII 字符（如中文、空格），须先进行
UTF-8百分号编码（Percent-encoding），否则刷新任务可能无法生效。
刷新与预热注意事项
费用说明
刷新和预热功能本身不收取任何操作费用。
但这两种操作都会触发边缘节点回源拉取资源，由此产生的回源流量和回源请求次数将会产生费用。计费标准遵循所使用的源站类型：
大规模刷新或预热操作（尤其短时间内集中执行）可能导致回源成本增加，请在操作前评估潜在的成本影响。
操作步骤
刷新资源
登录CDN控制台。
在左侧导航栏，单击刷新预热。
在刷新缓存/预热缓存页签，选择操作类型为刷新。
根据需求选择刷新方式并提交任务。
刷新方式 | 操作说明 |
URL刷新 | 目的：精确失效一个或多个具体文件的缓存。操作：刷新内容输入框内输入完整的 URL（包含 |
目录刷新 | 目的：失效指定 URL 目录下所有文件和子目录的缓存。操作：输入完整的目录 URL，须以 |
正则刷新 | 目的：按正则表达式匹配 URL 路径，批量失效符合规则的资源缓存。适用于精确到路径的刷新场景，例如按版本号、文件类型或路径段批量刷新资源。操作：输入带有正则表达式的 URL。例如： |
单击提交，系统开始执行刷新任务。
刷新任务一旦提交成功，无法中止。
刷新任务通常需要 5~6 分钟在全网生效。如果缓存过期时间小于此值，则无需手动刷新。
如果在OSS控制台开启了CDN缓存自动刷新，则无法通过 CDN 控制台查看 OSS 的缓存自动刷新任务。
预热资源
登录CDN控制台。
在左侧导航栏，单击刷新预热。
在刷新缓存/预热缓存页签，选择操作类型为预热。
预热内容输入框内输入需要预热的完整文件 URL，每行一个。不支持预热目录。例如：
https://www.example.com/install/package.zip。单击提交，系统开始执行预热任务。
预热任务一旦提交成功，无法中止。
预热任务的完成时间取决于文件大小、数量和源站性能，通常需要 5~30 分钟。
参数 | 说明 |
预热类型 | 仅支持URL预热，不支持目录预热。 |
URL | 输入的URL须带有 URL预热配额（每日）：默认情况下，一个账号每日最多可提交1000条URL预热任务，如账号日带宽峰值大于200Mbps，可申请提升每日配额，阿里云将根据实际业务需求进行评估和配置。每次最多可提交100条URL预热任务。 预热队列规则：每个账号的预热队列最大为100,000条URL，按URL提交先后顺序进行预热；当预热队列中待预热的URL达到100,000条时，将拒绝接收新的预热任务。 预热速度：预热任务的执行速度与需要预热资源的文件平均大小有关，文件平均大小越小，预热速度越快。 |
自动化刷新或预热
存在以下情况时，建议使用使用自动化脚本刷新和预热：
无开发人员，需手动提交刷新预热任务，运维成本高。
刷新或预热URL过多，分批提交导致效率低。
需要人工或程序判断刷新预热任务是否正常进行。
验证结果
手动查询
操作记录页签可查看资源刷新或预热的详细记录和进度。进度为100%表示任务执行完成。刷新或预热的数量过多会影响任务的完成进度，请耐心等待。
接口查询
调用查询刷新预热任务-按ID接口，查询刷新或预热任务是否完成。
命令行验证
执行命令curl -I <资源链接>，系统显示结果如下：
存在X-Cache的情况：
X-Cache为HIT，说明此次请求命中缓存，预热成功。X-Cache为MISS，说明此次请求未命中缓存，预热任务未完成或预热失败，请重新预热。
不存在X-Cache的情况：
如果不存在X-Cache，说明该资源未接入CDN，请参照快速接入阿里云CDN，先将该URL的域名接入阿里云CDN，再进行资源的预热。
使用限制
刷新和预热功能存在配额限制，超出限制后任务将被拒绝。如需提升配额，可前往配额管理申请：
操作类型 | 方式 | 配额限制 | 管理额度 |
刷新 | URL刷新 | 每个账号每日最多10000条 | |
目录刷新 | 每次最多提交100条；每个域名每分钟最多100条 | ||
正则刷新 | 每个账号每日最多20条 | ||
预热 | URL预热 | 每次最多提交100条；每个账号每日最多1000条 |
参考：CDN的缓存刷新机制
CDN 针对目录刷新和正则刷新提供两种缓存刷新机制：标记刷新和强制刷新，适用于不同场景，帮助灵活高效地管理缓存内容。
标记刷新（CDN默认策略）
适用场景：常规内容更新，如发布新版静态文件。
机制：这是目录刷新和正则刷新在控制台上的默认行为。CDN 边缘节点在回源时，会携带
If-Modified-Since或If-None-Match请求头。源站会根据这些头信息判断资源是否已更新。效果：如果源站资源未变更，源站将返回
304 Not Modified状态码，CDN 边缘节点会继续使用旧的缓存副本，不会消耗回源流量。这是一种节省成本和源站资源的优化方式。注意：若需彻底清除缓存（如违规清理、配置变更、同名文件更新），标记刷新可能无法满足需求，请使用强制刷新。
强制刷新
适用场景：紧急清理违规或错误资源、修复错误的
Cache-Control响应头配置后需要强制全网更新、源站文件同名更新等场景。机制：通过刷新缓存提交刷新任务时，将参数
Force设置为true来触发。此模式下，CDN 边缘节点会无条件地将缓存资源标记为失效，不再进行304校验。效果：下次访问该资源时，CDN 边缘节点将必须回源获取新版本，即使源站上的文件并未改变。
API 强制刷新参数示例：
{
"ObjectType": "Directory",
"ObjectPath": "https://www.example.com/static/",
"Force": true
}关键参数说明：
ObjectType：填写Directory（目录）或File（文件）。ObjectPath：填写以/结尾的完整目录路径，或具体的文件URL。Force：设置为true开启强制刷新，忽略源站的If-Modified-Since/If-None-Match校验，直接清除缓存。