本文为您介绍CDN缓存相关的常见问题。
CDN缓存清理机制是什么？
缓存在CDN节点上的资源，如果该资源的访问热度较低（同一个CDN节点上的同一个资源被客户端访问的频次较低），那么很可能会在缓存过期之前被CDN节点上其他访问热度较高的资源覆盖。
CDN默认的缓存规则是什么？
CDN节点在收到源站响应的静态文件资源的时候，会按照以下的缓存规则来执行（数值越小，优先级越高）：
源站响应
pragma:no-cache、cache-control:no-cache（或者no-store，或者max-age=0）时，不缓存。CDN控制台设置的缓存过期时间或者状态码过期时间。
说明若CDN请求同时命中多条规则，有且仅有一条规则会生效，优先级为：权重>规则创建时间。
有多条缓存规则的情况下，建议每条缓存规则都设置不同的权重（权重越大优先级越高），通过权重来控制规则执行优先级。
权重相同的规则生效优先级：先创建的＞后创建的，与规则类型无关。
源站配置其他缓存规则，优先级由高至低为：
cache-control>expires>last-modified>ETag。源站响应中使用
cache-control设置过期时间，取值为max-age或s-maxage，并且max-age或s-maxage的值大于0，例如：cache-control:max-age=3600。如果同时存在max-age和s-maxage，则以s-maxage的值为准。源站响应中使用
expires设置过期时间，例如：expires:Tue, 25 Nov 2031 17:25:43 GMT。源站响应中携带了
ETag或last-modified，则使用以下规则来计算缓存时间：有
last-modified，使用公式（当前时间-last-modified）* 0.1，计算结果在10秒~3600秒及之间的，取计算结果时间；小于10秒的，按照10秒处理；大于3600秒的，按照3600秒处理。只有
ETag，缓存10秒。
源站返回的数据中
ETag、last-modified、cache-control和expires这些缓存相关的响应头都没有携带，则默认不缓存。
如何判断CDN缓存是否成功？
阿里云CDN对于文件是否支持缓存，您可以通过检查HTTP响应头中的相关字段来判断。
X-Cache: 表示请求是否命中了CDN缓存。如果值为HIT，则表示请求命中了CDN缓存；如果值为MISS或者字段不存在，则表示请求没有命中缓存。Age: 表示该文件在CDN节点上缓存的时间，单位为秒。只有文件存在于节点上Age字段才会出现，当文件被刷新后或者文件被清除的首次访问，在此前文件并未缓存，无Age头部字段。需要注意当Age为0时，表示节点已有文件的缓存，但由于缓存已过期，本次无法直接使用该缓存，需回源校验。X-Swift-CacheTime: 表示CDN节点上的允许缓存时间，即该文件可以在CDN节点上缓存多久，是指文件在CDN节点缓存的总时间。计算还有多久需要回源刷新=X-Swift-CacheTime–Age。X-Swift-SaveTime：表示资源首次被缓存到CDN节点上的时间。这个时间是按照格林尼治标准时间（GMT）记录的，若要转换为中国北京时间，需要加上8小时。例如，如果X-Swift-SaveTime的值为2023-04-17 14:30:49，那么该资源在北京时间中的缓存开始时间为2023-04-17 22:30:49。
为了查看这些HTTP响应头，您可以通过以下两种方式查看您的内容是否缓存到CDN：
方式1：使用浏览器的开发者工具（如Chrome的开发者工具）
方式2：使用curl命令查看资源缓存情况
curl "http://example.com/path/to/response.html" -voa
如何解决URL的传递参数为变量导致CDN缓存命中率低的问题？
可能是因为没有开启CDN的忽略参数功能，详情请参见URL的传递参数为变量导致CDN缓存命中率低。
如何设置文件不缓存直接回源？
根据您的需求，针对不希望缓存的资源，按照目录、文件路径、文件类型设置对应的缓存时间，设置如下：
类型：选择目录或文件后缀名。
地址：填写您不想缓存的具体资源路径或文件名后缀，例如，需要设置
php,jsp,asp类型的动态文件和admin目录下的所有文件不缓存。过期时间：将过期时间设置为“0”，表示不缓存该类型的资源。
权重：可按照需要调整权重值，权重越高，在缓存命中判断时优先级越强。
详情请参见配置缓存过期时间。
在CDN控制台缓存过期时间设置为0，为何访问到的资源仍然不是最新内容？
在CDN控制台将缓存过期时间设置为0，通常是为了CDN节点上的内容不被缓存，从而每次请求都会直接回源站获取最新内容。然而，如果您发现访问到的资源仍然不是最新的内容，可能有几个原因：
浏览器本地缓存：用户的浏览器也可能缓存了旧的内容，即使CDN和源站都没有缓存，如果用户本地缓存未过期，也可能导致加载的是旧版资源。建议清除本地浏览器缓存或使用无痕隐私模式来测试。
配置生效延迟：虽然设置了缓存过期时间为0，但可能需要一定时间让这个设置在所有CDN节点上生效。另外，如果CDN节点尚未检测到缓存规则的更改，它可能仍然会返回旧的缓存内容。
源站缓存未刷新：源站服务器可能也有自己的缓存机制。如果源站缓存了内容并且没有及时更新，CDN节点回源时可能获取的是源站的旧缓存。
节点缓存清除延迟：如果在修改配置前，CDN节点已经缓存了某个资源，虽然现在设置缓存时间为0，但已缓存的资源可能需要一段时间才会从所有CDN节点中完全清除。您也可以通过手动刷新缓存，确保立即从源站获取最新内容，详情请参见手动刷新资源。
源站变更文件后，CDN节点上的缓存会主动、实时更新吗？
源站变更文件后，CDN节点上的缓存不会主动、实时更新。通常情况下，一旦某个文件被缓存到CDN节点上，它会根据配置的缓存策略来决定何时过期或刷新。
CDN节点根据您在控制台配置的缓存过期时间更新缓存；若源站变更文件，但CDN缓存未达到过期时间，不会主动回源更新文件，此时将造成源站文件和CDN缓存的文件不一致，详情请参见配置缓存过期时间。
您可以通过CDN提供的刷新缓存手动清除缓存。这种方式可以立即删除CDN节点上的特定文件或目录的缓存，使得下一次请求会回源获取最新的内容。
通过控制台操作：手动刷新资源
调用API接口：RefreshObjectCaches - 刷新缓存
影响CDN缓存命中率下降的因素有哪些？
影响阿里云CDN缓存命中率下降的因素如下，更多场景关于影响缓存命中率的因素介绍请参见提高CDN缓存命中率。
刷新缓存：手动或自动刷新缓存操作可能导致短时间内命中率下降。
带宽突增：当带宽在短时间内大幅度增加时，会导致CDN节点回源请求增多，从而降低缓存命中率。具体可参见刷新和预热资源。
CDN节点访问新内容：如果CDN节点频繁访问首次请求的新内容，也会导致回源较多，进而表现出缓存命中率的下降趋势。
缓存规则调整：对CDN缓存策略进行修改或调整可能会影响缓存命中率，例如未配置合适的缓存过期时间或者缓存策略设置不当。
URL中带有可变参数：URL中问号（?）后的参数变化会导致不同的URL请求被视为不同的资源，即使实际指向的是同一份内容，这也会造成CDN缓存命中率降低。具体可参见忽略参数。
未合理配置缓存过期时间：对于不同更新频率的静态文件，如未根据实际情况设置合理的缓存过期时间，可能会导致缓存资源过早失效，从而影响缓存命中率。具体可参见配置缓存过期时间。
如何排查CDN缓存命中率较低的问题？
缓存命中率较低可能会导致内容加载速度变慢，对源站造成一定的负载压力。排查缓存命中率低的问题，请参见CDN缓存命中率较低排查方法。
如何设置缓存全局生效？
您可以通过设置缓存过期时间来实现缓存全局生效。设置时，类型选择目录后，在地址栏用正斜线（/）匹配所有目录。具体操作请参见配置缓存过期时间。
缓存配置为什么没有生效？
如果您配置了缓存规则，在使用过程中发现此缓存规则未生效，可能是以下原因：
生效延迟：缓存规则的修改或新增通常需要一段时间才能，请您在规则生效后再验证。
缓存更新机制：如果您对已缓存的内容修改了缓存规则，新规则不会立即应用到已经缓存在CDN节点上的内容。这些内容需要等到原来的缓存过期后才会回源重新获取并按照新的规则进行缓存。
缓存刷新操作未执行：在更改缓存设置后，如果没有手动刷新缓存，则旧的缓存内容将继续被提供给用户，直到自然过期。如果您想要立即生效，请在修改缓存规则后执行缓存刷新操作，详情请参见刷新和预热资源。
缓存响应头设置不当：检查源站发送的HTTP响应头里的
Cache-Control和Expires标头是否正确设置。例如，如果设置了Cache-Control: no-cache或no-store，则会指示CDN和浏览器不缓存内容。缓存规则有优先级：若CDN请求同时命中多条规则，有且仅有一条规则会生效，优先级为：权重>规则创建时间。
有多条缓存规则的情况下，建议每条缓存规则都设置不同的权重（权重越大优先级越高），通过权重来控制规则执行优先级。
权重相同的规则生效优先级：先创建的＞后创建的，与规则类型无关。
配置示例：为加速域名
demo.aliyun.com配置以下缓存策略，CDN节点回源下载资源http://demo.aliyun.com/image/example.png，虽然以下两条规则都匹配到了，但是因为这两条规则的权重相同，因此要判断规则创建的时间，先创建的规则优先级高于后创建的，因为目录/image这条规则创建的时间更早，所以系统最终生效的是目录类型这条规则。
通过HTTP响应头配置CDN跨域资源共享（CORS）及注意事项
设置适当的HTTP响应头，允许来自不同源的请求访问资源，详情请参见配置跨域资源共享。
为什么已经配置了响应头Access-Control-Allow-Origin，但是访问资源仍提示跨域问题，response header中没有配置的响应头？
如果您在阿里云CDN中配置了回源响应头，如Access-Control-Allow-Origin等，但是在客户端访问资源时遇到跨域问题，并且在响应头（response header）中没有看到这些配置的响应头，可能原因有以下几点：
可能的原因
配置未生效或错误：可能是配置没有正确设置或尚未生效，导致CDN没有按照预期返回跨域响应头。
CDN缓存：CDN节点可能缓存了旧的响应头信息，这会导致即使您已更改配置，也仍然返回旧的头信息。
源站问题：如果您在CDN上配置了跨域响应头，但是源站的响应中也包含了跨域响应头，并且这些响应头与CDN的配置冲突，这可能会导致问题。在这种情况下，需要统一CDN和源站的配置。
浏览器缓存：浏览器可能缓存了旧的响应，导致它并未发起新的请求以获取更新后的响应头。
解决方案
验证配置：确认CDN配置已正确设置并且已经生效，特别是跨域相关的响应头设置。
清除CDN缓存：您可以使用CDN的刷新功能清空已缓存的内容，然后再次访问资源。具体请参见刷新和预热资源。
检查源站设置：确认源站不会返回与CDN配置冲突的跨域响应头。建议将源站回源响应头与节点响应头中的跨域头设置为也一致，如果配置不一致，可能会导致冲突。
清除浏览器缓存：清空浏览器缓存，或使用无痕（隐私）模式测试，确保浏览器获取最新的响应头。
联系技术支持：如果您尝试了上述所有方法，但问题仍然存在，可能是CDN服务方面的问题。请联系阿里云CDN的技术支持或提交工单寻求帮助。
节点HTTP响应头和回源HTTP响应头有什么区别？
节点HTTP响应头和回源HTTP响应头虽然都是HTTP响应头，但它们是两个不同的概念，代表了在缓存架构中不同环节所返回的HTTP头部信息。
节点HTTP响应头：是由CDN节点发送给客户端（如浏览器）的HTTP响应头。当CDN节点在接收到客户端请求时，如果该节点上已经有缓存的内容，就会直接将这些内容连同相应的HTTP头部信息一起返回给客户端。这个过程不需要CDN节点向源站发起新的请求。
回源HTTP响应头：是源站发送给CDN节点的HTTP响应头。当CDN节点上的缓存过期或者没有命中缓存时，CDN节点会向源站发起请求来获取最新内容。源站返回的内容以及相关的HTTP头部信息就是回源响应头。这些头部信息被CDN节点接收并处理，之后可能被存储下来以便下次使用。
因此，节点HTTP响应头和回源HTTP响应头的区别在于它们的应用场景和控制的对象不同。节点HTTP响应头主要用于控制客户端和CDN节点的缓存行为，而回源HTTP响应头则主要用于控制源站与CDN节点之间的缓存行为。在实际应用中，它们通常会共同使用，以实现高效、精确的缓存控制。关于节点HTTP响应头的更多信息，请参见配置回源HTTP响应头。
异常状态码缓存规则是什么？
对于204、305、400、403、404、405、414、500、501、502、503和504状态码，缓存规则如下图所示：
开启配置Range回源功能，缓存规则如下：
非200、206状态码（包含但不限于204、305、400、403、404、405、414、500、501、502、503和504状态码）的情况下，均不缓存。
200、206状态码按照阿里云CDN默认缓存规则及优先级进行缓存。
收到5xx状态码会删除已缓存的分片文件（回源超时不会删除缓存文件）。
说明Range回源情况下，源站会把一个大文件分割成多个小的文件分片来返回给CDN节点。比如有个文件被分割成了10个分片，CDN节点已经缓存了5个分片，在请求第6个分片时，源站响应了5xx状态码，这时会把前面已经缓存的5个分片全部删除。
未开启配置Range回源功能，按照如下规则缓存：
如果源站返回
set-cookie响应头，CDN不缓存。如果源站没有返回
Set-Cookie响应头，则遵循CDN控制台配置的状态码过期时间来缓存，配置多条规则时生效方式请参考多条规则生效优先级说明。如果源站没有返回
Set-Cookie响应头，CDN控制台也没有配置状态码过期时间，则按照源站设置的Pragma、Cache-Control或者Expires响应头来缓存。如果源站没有返回
Set-Cookie、Pragma、Cache-Control或者Expires响应头，CDN控制台也没有配置状态码过期时间，则默认缓存1秒。
对于303、304、401、407、600和601状态码，CDN均不进行缓存。