阿里云CDN加速Hexo博客

之前我曾经给自己的博客简单配置过一次 CDN 加速，但当时对 CDN 的工作机制、回源逻辑以及 GitHub Pages 的域名策略理解并不充分，配置也比较“凭感觉”。虽然名义上接入了 CDN，但实际访问体验并没有明显改善，博客在国内访问时依然偏慢，这件事也一直被我搁置了下来。

最近刚好有一段相对完整的时间，于是决定重新系统地梳理一遍整个配置过程，从 DNS → CDN → GitHub Pages → HTTPS → 缓存策略 逐层检查，而不是简单地“把域名丢进 CDN 就完事”。

目前博客的基本情况是：
博客部署在 GitHub Pages 上，原始访问地址为 ab4ndon.github.io，并且已经绑定了自定义域名 kongcm.cn，访问会从 ab4ndon.github.io 自动跳转到 kongcm.cn。在此基础上，我希望 以 kongcm.cn 作为唯一对外入口，引入阿里云 CDN 对博客进行加速，同时保证访问路径清晰、HTTPS 正常、且不会引入额外的重定向问题。

在重新配置的过程中，实际踩了不少坑，网上相关教程较少，并且我在使用AI辅助的过程中也踩了一些坑，尤其是 回源 Host、GitHub Pages 的 canonical 域名机制 这一块，非常容易配置错误。本文将完整记录这次重新配置 CDN 的过程，以及中间遇到的问题和对应的解决方案。

阿里云 CDN 添加加速域名

在使用 CDN 之前，需要明确一点：
CDN 并不是“替代源站”，而是“站在用户和源站之间的缓存与调度层”。
因此第一步并不是修改博客部署方式，而是让 CDN 成为访问入口。

进入阿里云控制台：

阿里云 CDN → 域名管理 → 添加域名

填写以下信息：

• 加速域名：yourdomain.com
  这是用户实际访问的域名，也是 CDN 对外提供服务的入口。
• 业务类型：图片小文件 / 全站加速
  对于静态博客而言，两者都可以，区别不大。
• 加速区域：全球（或仅中国大陆）
  如果博客主要面向国内访问，可以选择中国大陆。

这一步的本质是：
告诉阿里云 CDN：“以后所有访问 yourdomain.com 的请求，都由你来接管。”

可以在性能优化那边把一些优化手段都开启：

配置源站

CDN 接管流量之后，仍然需要知道：
当缓存中没有内容时，该去哪里取原始数据，这就是“源站”。

在 CDN 域名配置中设置：

• 源站类型：IP
• 源站地址（GitHub Pages 的固定 IP）：

185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153

建议全部填写，CDN 会自动进行负载与容错。

这里选择 IP 而不是域名，是为了避免 DNS 再次解析带来的不确定性，也能减少一层潜在的重定向问题。

此时可以理解为：

CDN 已经知道“内容放在哪里”，
但它还不知道“应该以谁的身份去访问这些内容”。

配置“回源 Host”

回源 Host 是整个配置过程中最容易被忽略、但影响最大的参数。

定义先行：

回源 Host = CDN 向源站发起 HTTP 请求时，在请求头中携带的 Host 字段。
它决定了源站“认为自己是通过哪个域名被访问的”。

进入：

CDN → 域名管理 → yourdomain.com → 回源配置

设置：

• 回源协议：HTTPS
  保证回源链路加密，避免混合内容和协议降级。
• 回源 Host：yourdomain.com

这一项并不是“随便填一个能访问源站的地址”，而是必须与对外访问域名保持一致。

踩坑一：回源 Host 填成 xxx.github.io 导致死循环

一开始由于对回源 Host 的理解不清晰，按照 Qwen 的建议，将回源 Host 填成了 GitHub Pages 的地址 ab4ndon.github.io，结果页面无法正常访问，浏览器提示重定向次数过多。

此时实际发生的访问流程是：

浏览器
 → https://kongcm.cn
   → CDN
     → ab4ndon.github.io（回源）
       → 301 到 https://kongcm.cn
         → CDN
           → 浏览器
             → https://kongcm.cn
               → ……

问题的根源在于：

• GitHub Pages 已经认定 kongcm.cn 是该站点的主域名
• 当它收到 Host: ab4ndon.github.io 的请求时
• 会主动返回 301，把访问“纠正”回 kongcm.cn

而 CDN 又会把这个 301 原样转发给浏览器，最终形成闭环。

表现出来的症状就是：

• 页面一直加载
• curl -IL 看到连续的 301
• 浏览器报 ERR_TOO_MANY_REDIRECTS

---

踩坑二：删除 CNAME 后被重定向回 github.io

为了解决踩坑一中的重定向循环，Qwen 给出的建议是：
取消 GitHub Pages 对自定义域名的绑定，也就是删除 source/CNAME，或在 Pages 设置中移除自定义域名。

这样做之后，页面确实可以访问了，但新的问题出现了：
访问 kongcm.cn 会被重定向到 ab4ndon.github.io。

此时系统状态是：

• GitHub Pages：
  • 已删除 CNAME
  • 不再绑定 kongcm.cn
  • canonical domain 回退为 ab4ndon.github.io
• CDN：
  • 对外访问域名：kongcm.cn
  • 回源 Host：ab4ndon.github.io（或默认）

真实访问路径如下：

浏览器
 → https://kongcm.cn
   → CDN
     → ab4ndon.github.io（回源）
       → 301 到 https://ab4ndon.github.io
         → 浏览器
           → https://ab4ndon.github.io
             → GitHub Pages（200）

在这个状态下：

• GitHub Pages 不再承认 kongcm.cn 是合法主域名
• 它会把所有访问统一规范化到 ab4ndon.github.io
• CDN 只是中转者，并不会阻止这一行为

页面能访问，但自定义域名“失去了主权”。

这两个坑看似相反，实则指向同一个结论：

GitHub Pages 的 canonical 域名
与 CDN 的回源 Host 必须保持一致。

• GitHub Pages 认谁是主域名
• CDN 回源时就必须“以谁的身份”访问源站

一旦两者不一致，就一定会出现 301 重定向问题。

配置 DNS

在 CDN 配置完成后，还需要让 DNS 层把请求导向 CDN。

阿里云 CDN 会提供一个 CNAME，例如：

yourdomain.com.w.kunlungr.com

在域名解析中添加：

主机记录：@
记录类型：CNAME
记录值：yourdomain.com.w.kunlungr.com

图中下面这条解析记录是之前绑定自定义域名的时候添加的，这里可以忽略。这样做之后：

• 所有访问 yourdomain.com 的请求
• 都会先到达 CDN 节点
• 再由 CDN 决定是否回源

验证 CDN 是否真正生效

使用 curl 验证

curl -I https://yourdomain.com

关键关注响应头中的信息：

• Server: Tengine
  表示请求已经由阿里云 CDN 接管。
• Via: cache*.l2cn****
  表示请求经过了国内 CDN 节点。
• X-Cache: HIT / MISS
  表示是否命中缓存。

只要出现以上任意两项，就可以确认 CDN 已经生效。

验证缓存命中情况

再次访问同一地址：

curl -I https://yourdomain.com

如果看到：

X-Cache: HIT TCP_MEM_HIT
Age: >0

说明：

• 内容已经缓存在 CDN 节点内存中
• 后续访问不再回源 GitHub Pages
• 实际访问速度会明显提升

小结

整个配置过程中，真正决定成败的并不是 DNS，也不是证书，而是：

• 是否理解 CDN 回源与源站之间的 Host 关系
• 是否让 GitHub Pages 的 canonical 域名 与 CDN 回源 Host 完全一致