CDN 缓存命中率突然下降是什么原因 #

如果您发现加速域名的缓存命中率突然下降，可以检查是否存在以下某个情况：

• 最近执行了缓存刷新操作。缓存刷新后，短期内回源请求会增加，导致命中率下降。
• 带宽突增。带宽突增可能的原因是 CDN 短期内收到了大量的请求，但是请求的文件未被缓存或在缓存中已过期，导致回源请求增加，缓存命中率下降。常见的场景是您的站点在短时间内添加了大量热点页面。
• CDN 节点向源站请求大量的文件：由于回源请求较多，导致命中率下降。常见的场景是您的站点首次接入 CDN 或者您站点上添加了大量的文件。
• 最近调整了域名配置：缓存键值、缓存规则、Range 回源 等功能的配置调整都可能会影响缓存命中率。
• 源站响应未包含缓存相关的头部，导致文件未被 CDN 缓存。

如何提升 CDN 缓存命中率 #

背景

內容分发网络是由遍布全国各省份、覆盖各运营商的海量缓存节点组成。通过将站点内容分发至靠近用户的缓存节点，使得用户可就近快速获取所需内容，从而有效地解决公网拥塞、网络延迟等问题，优化用户访问体验。因此，如果节点缓存的內容越多，加速域名的内容分发性能就越好，同时还可以减轻源站的压力。

您可以通过 CDN 的 命中率指标 来查看加速域名下命中缓存的请求比例。

缓存命中率包括请求命中率和流量命中率：

• 请求命中率 = 命中缓存的请求数 ÷ CDN 收到的总请求数
• 流量命中率 = CDN 对命中缓存的请求所响应的字节数 ÷ CDN 对所有请求所响应的字节数

提升缓存命中率的方法

CDN 的缓存逻辑是怎么样的 #

CDN 中预设的缓存策略

预设缓存策略为 "遵循源站"，对所有文件生效，优先级最低，并且删除。"遵循源站" 指示在以下情况下，CDN 不缓存请求的文件：

• 源站响应不包含 Cache-Control 或 Expires 头部。
• 源站响应头 Cache-Control 是以下任意值：
  • max-age = 0
  • no-store
  • no-cache
  • private
• 源站响应头 Expires 所指示的时间早于当前时间。

预设缓存策略确保了任何请求都能匹配到一个缓存策略。

如果预设缓存策略无法满足您的要求，您可以配置其他缓存策略，说明如下：

关于详细的缓存行为描述，参见 缓存规则详细描述。

异常状态码会被缓存吗 #

默认情况下不会。CDN 的缓存策略仅对源站响应码为 2xx 的文件生效。但是您可以配置 状态码缓存 来对 4xx 和 5xx 的状态码进行缓存。

CDN 是否支持配置永久缓存 #

不支持。您能设置的最长缓存过期时间为 365 天。CDN 节点会定期删除访问量较少的缓存资源。

如何判断请求是否命中 CDN 的缓存 #

在 CDN 的响应中，X-Response-Cache 头部指示请求是否命中了缓存。

• edge_hit：表示命中缓存。
• miss：表示未命中缓存。

您也可以通过 配置 HTTP 响应头 来获取 cdn_cache_status 变量的值。该变量指示了请求是否命中了缓存。

如何保障缓存文件和源站文件的同步 #

对于时效性要求不高的文件，您可以采用以下方法：

• 如果文件的更新频率高，您可以设置一个较短的缓存时间。
• 如果文件的更新频率低，您可以设置一个较长的缓存时间。这样可以尽可能保障缓存中文件的新鲜度，减少回源请求的次数。

对于时效性要求高的文件，您可以采用以下方法：

• 如果源站文件有了更新，您可以通过 缓存刷新 操作，使得该文件在缓存节点上被标记为过期，避免 CDN 将缓存节点上的老版本文件响应用户的请求。如果文件较大，建议您在 缓存刷新 操作后对该文件进行 文件预热 操作，将最新的文件主动缓存到缓存节点，从而提升缓存命中率，降低源站的压力。

CDN 如何处理源站的 301/302 响应 #

如果源站返回 301/302 状态码，默认情况下，CDN 会将该状态码发送给客户端，让客户端去处理。如果重定向后的文件是静态的，建议您 启用回源重定向跟随。启用后，当源站返回 301/302 时，CDN 会尝试获取重定向后的文件。如果获得了目标文件，CDN 根据缓存规则来缓存该文件，并将该文件返回给客户端。这样可以有效提升在源站返回 301/302 时的用户体验。

源站资源是有效的，但为什么 CDN 返回 404 #

先检查加速域名的 回源 HOST 配置是否正确。如果源站上存在多个站点，您需要通过回源 HOST 指定回源请求需要访问的实际站点。默认情况下，回源 HOST 与加速域名相同。

如果 "回源 Host" 的配置正确但问题依旧存在，请 提交工单。

示例说明
源站为 www.test.com。该源站上提供服务的实际站点是 img.test.com。在这个情况下，如果您未将 回源 Host 设置为 img.test.com，源站的请求就会收到 404 响应。

CDN 是否支持第三方存储桶配置 #

支持。CDN 的源站类型可以是 火山引擎 TOS，也可以是以下任意第三方对象存储服务：

• 阿里云
• 腾讯云
• Amazon AWS

参见 新增源站。

CDN 对源站的健康检查机制是什么 #

回源重试发生时的源站选择逻辑
当 CDN 无法连接某个源站时，会基于以下规则来选择切换到的源站：

• 主源站的优先级高于备源站。
• 只有当所有主源站的 IP 地址都在 "不可用源站" 列表中时，CDN 才会选择备源站。
• 源站是基于权重来选择的。权重高的源站优先被选择。如果两个源站的权重相同，内容分发网络使用轮询方式选择源站。

"不可用源站" 列表
如果连续 10 次都无法与某个源站建立 TCP 连接，CDN 会将该源站的 IP 地址添加到 "不可用源站" 列表中。

在尝试与某个源站建立 TCP 连接前，CDN 会检查 "不可用源站" 列表。如果该源站的 IP 地址在列表中，CDN 会同时进行以下操作：

• 放弃连接该源站，然后根据 回源重试发生时的源站选择逻辑，选择一个其他源站。
• 对该源站进行异步探测。如果可以与该源站建立 TCP 连接，内容分发网络会将该源站的 IP 地址从"不可用源站"列表中删除。每次探测的最小间隔时间是 5 秒。

站点接入 CDN 后，TOS 存储桶上的跨域访问（CORS）配置为什么失效了 #

问题描述
在以下场景中，当站点 B 接入 CDN 后，您在 TOS 存储中桶中更新了 CORS 配置。但是该配置没有生效。

问题原因
当用户第一次访问站点 B 上的某个文件时，CDN 向 TOS 存储桶请求并缓存该文件。与文件一起被缓存的还有源站的响应头。然后 CDN 将该文件与源站响应头一起发送给用户。如果存储桶上有 CORS 配置，源站响应头会包含 Access-Control-Allow-Origin 头部。

如果您更新了源站上的 CORS 配置，新配置不会更新到 CDN 的缓存。用户再次请求该文件时，CDN 发送给用户的是缓存的文件以及缓存的源站响应头，不是源站最新的响应头。如果缓存中的文件过期了但是回源校验的结果是源站上该文件未过期，那么 CDN 发送给用户的内容中依然不包含源站最新的响应头。

解决方案
在 CDN 中，通过 HTTP 响应头部配置 设置与源站相同的 CORS 配置。具体配置如下：

• 响应头部操作：设置
• 响应头部名称： Access-Control-Allow-Origin
• 取值方式：常量
• 响应头部取值：指定允许跨域访问的 URL，例如 https://www.example.com。
• 如果您需要配置多个 URL，并且希望 Access-Control-Allow-Origin 响应头仅包含用户请求中 Origin 头部中的 URL，您可以设置 跨域校验 为 开启。

如何通过响应头定位请求异常原因 #

当客户端请求由于 访问控制配置拦截 或 限速 等原因受阻时，CDN 会在 HTTP 响应中默认新增 X-Exception-Info 响应头，以协助您快速排查并定位异常原因。

异常响应头示例
如下示例所示，CDN 响应头中包含了 X-Exception-Info: deny by area access rule，表明该请求被您的“地域访问控制”规则拦截。

Server: Byte-nginx
Content-Type: text/html; charset=utf-8
Content-Length: 26
Connection: keep-alive
Age: 185
Cache-Control: max-age=3600
X-Bdcdn-Cache-Status: TCP_HIT
X-Powered-By: PHP/5.4.16
X-Request-Id: f984be27e6cfef3ac5238d2231dad7fc
X-Request-Ip: 120.234.91.233
X-Response-Cache: edge_hit
X-Response-Cinfo: 120.234.91.233
X-Tt-Trace-Tag: id=5
Date: Thu, 15 Aug 2024 07:15:57 GMT
via: cache07.gzcm06
X-Exception-Info: deny by area access rule

常见异常类型与响应信息对照表
如果异常是由于您的域名配置（如访问控制策略或流量检测等）引起的，您可以根据下表中的响应信息排查对应的配置项：