工作原理请求到达CDN节点时，系统遵循以下决策流程（序号越小，优先级越高）决定是响应缓存副本，还是回源获取最新内容。
不缓存资源：源站响应pragma:no-cache、cache-control:no-cache（或者no-store，或者max-age=0）时，CDN遵循源站的策略，完全不缓存资源。
遵循控制台缓存规则：CDN控制台为指定目录或文件后缀名设置规则，且源站未配置上述不缓存规则，此时控制台缓存规则为最高优先级策略。
多条控制台缓存规则匹配时的优先级逻辑：
场景
优先级逻辑
示例
权重不同
权重值（1-99）大的规则优先生效。
规则A（目录/image/，权重50）和规则B（后缀.jpg，权重90）都匹配 image/a.jpg，则规则B生效。
权重相同
先创建的规则优先生效。
为域名配置权重同为60的目录规则（/static/）和后缀规则（.js），若目录规则创建时间早于后缀规则，则 /static/app.js 命中目录规则。
请求命中某条缓存规则后，不再继续匹配其他规则。
默认情况下，若源站响应 Pragma: no-cache 或 Cache-Control: no-cache/no-store/max-age=0，CDN节点不缓存该资源。如果需要强制缓存资源，可以在控制台配置缓存过期时间时勾选忽略源站不缓存标头。
CDN遵循源站缓存策略：若请求未命中任何CDN控制台规则，或命中的规则开启了优选遵循源站缓存策略，此时CDN将遵循源站的HTTP响应标头。响应头的优先级由高至低为：cache-control>expires>last-modified>ETag。
响应头
CDN 如何处理
注意事项与示例
Cache-Control
优先用 s-maxage（CDN 缓存时长），其次 max-age。
示例：s-maxage=86400, max-age=3600
Expires
过期时间，仅当无 Cache-Control 时生效。
示例：Expires: Wed, 21 Oct 2025 07:28:00 GMT
Last-Modified
Last-Modified是一个时间戳，表示资源最后被修改的时间。
缓存时间计算规则如下：
（当前时间-last-modified）* 0.1，计算结果在10秒~3600秒及之间的，取计算结果时间；小于10秒的，按照10秒处理；大于3600秒的，按照3600秒处理。
示例：Last-Modified: Wed, 21 Oct 2023 07:28:00 GMT
ETag
ETag是服务器为每个资源生成的一个唯一标识符，通常是一个哈希值或版本号。
ETag默认缓存10秒。
示例：ETag: "abc123"
CDN不缓存策略：若没有命中CDN控制台的缓存规则，并且源站也没有返回Cache-Control等缓存响应头，则CDN执行不缓存策略。
说明 CDN仅对源站响应200, 203, 206, 300, 301, 308, 410状态码的请求执行缓存策略。如需缓存其他状态码的请求（例如404），需在 缓存配置 > 状态码过期时间 页面设置。
操作步骤控制台（推荐）CDN控制台的域名管理页，单击目标域名右侧的管理。
在缓存配置 > 缓存过期时间页面单击添加，配置缓存规则。
参数
说明
类型
支持按目录或文件后缀名指定资源范围。• 目录：为路径下所有资源统一设置缓存规则。• 文件后缀名：为指定类型的文件统一设置缓存规则。
地址
根据所选类型填写：• 目录：以 / 开头（如 /static/），支持 / 匹配所有路径，每次仅支持添加一条。• 文件后缀名：输入一个或多个后缀，用英文逗号分隔（如 jpg,css），区分大小写，不支持 *。
过期时间
资源在CDN节点的缓存时长，最长3年。• 不常更新的静态资源（如图片、安装包）：建议 ≥1个月。• 频繁更新的静态资源（如 JS/CSS）：按需设置。• 动态内容（如 PHP/JSP）：建议设为 0秒（不缓存）。
优选遵循源站缓存策略
开启后，优先采用源站缓存策略，覆盖本规则配置。
忽略源站不缓存标头
开启后，CDN 将忽略源站返回的以下不缓存指令：Cache-Control: no-store、no-cache、max-age=0，以及 Pragma: no-cache，仍按CDN控制台规则缓存。
客户端跟随CDN缓存策略
开启后，CDN 会将自身生效的缓存策略（如 max-age=3600）通过响应头返回给客户端。
强制内容重新验证
仅在过期时间设为0秒时生效：
关闭（默认）：CDN的缓存过期时间配置为0时，CDN节点上不缓存文件，每次请求都需要回源获取内容。
开启：CDN的缓存过期时间配置为0时，支持在CDN节点上缓存文件，每次请求都需要回源验证缓存内容。
权重
规则优先级，取值 1~99，数值越大优先级越高。• 权重相同时，先创建的规则优先生效。• 任一规则命中后，不再匹配后续规则。
规则条件
可基于请求中的参数（如 Header、URL 参数等）进一步限定规则生效范围。• 默认不使用；如需配置，请在规则引擎中管理。
API调用BatchSetCdnDomainConfig接口，可以批量配置域名。更多功能参数的配置方法，敬请参考域名配置功能函数。
使规则变更立即生效配置变更或新增规则，仅对新缓存的资源生效。变更前已缓存的资源，将继续沿用旧的缓存策略直至过期。
要使新规则立即对全网生效，必须手动清理已有缓存。如果是规则变更，通过刷新资源功能执行刷新操作；如果是新增规则，通过预热资源功能执行预热操作。
生效验证配置完成后，可通过curl命令或浏览器开发者工具查看资源的HTTP响应标头，以判断缓存是否按预期工作。
1. 执行验证命令在终端上执行以下命令进行测试。
curl -I "https://your.domain.com/path/to/file.jpg"2. 解读关键响应头响应标头
常见值与解读
X-Cache
指示请求是否命中CDN缓存。- HIT：命中缓存。- MISS：未命中缓存，请求已回源获取资源。
Cache-Control
开启“客户端跟随CDN缓存策略”后，此标头会显示CDN传递给浏览器的缓存指令，如 max-age=3600。
X-Swift-CacheTime
资源在CDN节点上配置的缓存总时长，单位为秒。
应用于生产环境版本化文件名（推荐）：更新静态资源（如style.css）时，使用带版本或哈希值的新文件名（如style-v2.css或style-a1b2c3d.css），并更新HTML中的引用。此方式无需手动刷新CDN缓存，可确保用户立即获取最新内容，是推荐的缓存更新方式。
动静分离：为动态和静态资源使用不同域名或目录路径，并配置独立的、高权重的缓存规则，以避免策略混淆。例如，为/static/目录下的所有资源设置长缓存，为/api/目录下的资源设置不缓存。
善用浏览器缓存：开启“客户端跟随CDN缓存策略”，可减少对CDN的重复请求，提升加载速度并节省CDN流量。
避免缓存时间过短：过短的缓存时间会导致CDN频繁回源，无法起到加速效果，反而增加源站的流量消耗和成本。
注意缓存时间过长：过长的缓存时间会导致客户端获取数据更新不及时。对于需频繁更新的内容，务必配合刷新缓存操作或使用版本化文件名。
HTTP协议缓存控制机制说明在HTTP协议中定义了三种不同类型的协议头部来实现缓存控制相关的机制：
过期时间校验机制
客户端在向服务端请求资源的过程中，双方将为资源约定一个过期时间，在该过期时间之前，该资源（缓存副本）就是有效的，过了过期时间后，该资源（缓存副本）就会失效。
在HTTP协议中，控制缓存过期时间的Header常见的有下面这些：
头部名称
协议版本
作用
示例值
类型
Pragma
HTTP/1.0
Pragma用于表示内容是否为不缓存，通常取值no-cache，表示文件不缓存，常被用来兼容只支持HTTP1.0 协议的Server。
Pragma:no-cache
请求/响应
Expires
HTTP/1.0
Expires响应头包含日期/时间，表示在此时间之后，缓存内容将会过期。
如果使用了无效的日期，比如0，则代表该资源已经过期。
Expires: Wed, 21 Oct 2022 07:28:00 GMT
响应
Cache-Control
HTTP/1.1
Cache-Control响应头可以设置不同的指令来实现灵活的缓存控制，是目前主流客户端（如浏览器等）用于控制缓存的重要头部。
以下三个示例表示文件不缓存：
Cache-Control:no-cache
Cache-Control:no-store
Cache-Control:max-age=0
表示缓存有效期1小时的示例：Cache-Control:max-age=3600
请求/响应
资源标签验证机制
客户端在首次向服务端请求资源的过程中，服务端将在响应头中带上资源标签，资源标签可以作为客户端再次请求同一资源时的校验标识。客户端再次请求同一资源时，请求头中将会携带资源标签，若服务端校验后认为该资源没有更新，则响应HTTP状态码304，告诉客户端该资源没有更新，客户端可以继续使用本地缓存；若服务端校验后发现资源标签不匹配，则告诉客户端该资源已经被修改或者已经过期，客户端需要重新获取资源内容。
在HTTP协议中，控制缓存版本的Header常见的有下面这些：
头部名称
协议版本
作用
示例值
类型
Last-Modified
HTTP/1.0
Last-Modified表示资源的最后修改时间。
Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT
响应
ETag
HTTP/1.1
ETag表示当前资源特定版本的唯一标识符。
对比ETag能判断资源是否变化，如果没有改变，源站服务器不需要发送完整的响应。
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
响应
多副本协商机制
缓存软件使用关键字索引在磁盘中缓存的对象，在HTTP/1.0中使用资源的URL作为关键字，但可能存在不同的资源基于同一个URL的情况，要区别它们还需要客户端提供更多的信息，例如：Accept-Language、Accept-Charset等头部，为了支持这种内容协商机制（content negotiation mechanism），HTTP/1.1在响应消息中引入了Vary头部，该头部列出了请求消息中需要包含哪些头部用于内容协商。
多副本协商机制通常使用HTTP协议的Vary头部来区分不同的缓存副本，实现不同的客户端请求同一个资源的时候可以拿到不同缓存副本：
头部名称
协议版本
说明
示例值
类型
Vary
HTTP/1.1
常用示例：
服务端指定Vary: Accept-Encoding，告知接收端（例如：CDN节点）对于该资源需缓存两个版本（压缩和未压缩）。客户端向CDN请求同一个资源时，老版本浏览器获取未压缩资源（避免兼容性问题），新版本浏览器获取压缩资源（减少数据传输流量）。
服务端指定Vary: User-Agent，用来识别发送请求的浏览器类型，告知接收端（例如：CDN节点），根据不同的浏览器类型缓存对应版本的资源。
Vary: Accept-Encoding
Vary: Accept-Encoding,User-Agent
响应
常见问题缓存相关常见问题
CDN缓存清理机制是什么？
提高CDN缓存命中率
如何设置文件不缓存直接回源？
CDN是否支持多副本缓存？如何实现CDN的多副本缓存？