EdgeOne 与 Cloudflare 海内外分流 CDN

发布时间：2026-08-18 16:58:35更新时间：2026-08-22 20:40:00

🕒 阅读时间：8 分钟📝 字数：2888👀 阅读量：Loading...

AI 辅助声明：本文由 AI 协助整理写作，内容基于本次实际操作的记录与实测结果，所有结论均经过验证。

我的博客主站一直托管在腾讯 EdgeOne 的 EdgeOne Pages（腾讯的边缘静态托管平台，GitHub 的 myblog 仓库 push 后自动 CI 构建部署）。另外我把同一份仓库也部署到了 Cloudflare Pages，作为博客镜像，域名是 staluxmyblog.pages.dev。Cloudflare 在国内没有节点，免费版只就近到香港、日本这些地方，国内直连体验一直差点意思。

今天我把 xingwangzhe.fun 统一成唯一入口，用 DNSPod 线路分流把海内外访问分开：国内用户走腾讯 EdgeOne（主站），海外用户走 Cloudflare Pages（镜像）。两边都是免费版，全程没花一分钱。

先把最容易踩坑的一点说在前面：这套方案不是靠一台代理服务器实现的，也不是把域名的 NS 迁移到 Cloudflare。真正负责“国内还是海外”的是 DNSPod 的线路解析；EdgeOne 和 Cloudflare 只是两条解析记录背后的静态站点目标。

因此，操作顺序不能反过来。必须先在 DNSPod 里准备好同一个主机名的国内/默认线路和境外线路记录，再分别把对应的 CNAME 接入地址配置到 EdgeOne Pages、EdgeOne 加速域名和 Cloudflare Pages。只在平台后台绑定域名、没有提前准备 DNSPod 解析记录，平台不会凭空替你完成分流；临时把 NS 切到 Cloudflare 还会让 DNSPod 失去线路判断能力。

折腾史回顾

我对 CDN 的折腾不是第一次了：

2025 年 7 月拿到 EdgeOne 免费版兑换码，写了《腾讯Edgeone免费版体验》；
2026 年 2 月阿里云推出 ESA，我把博客《从edgeone迁移到esa》，用上了 ESA 中国站免费版，折腾一圈主站还是回到了 EdgeOne Pages；
Cloudflare Pages 这边一直是同一仓库的镜像，staluxmyblog.pages.dev。

这次要统一域名做海内外分流，EdgeOne 的「DNSPod 托管接入」跟 DNSPod 线路解析配合起来最顺，主站 EdgeOne + 镜像 Cloudflare 正好组成双 CDN。

方案：DNSPod 线路分流

xingwangzhe.fun 的 NS 一直在 DNSPod（elliot.dnspod.net / student.dnspod.net），所以最自然的做法就是利用 DNSPod 的按线路解析：同一个主机名配两条 CNAME，不同来源的 DNS 请求拿到不同的结果。

思路很简单：

为什么不用 NS 接入 Cloudflare？因为域名 NS 在 DNSPod，Cloudflare 侧只有 CNAME 接入的 zone（比如 xingwangzhe.site），所以 Cloudflare 这边只能当 CNAME 目标，DNSPod 负责决定谁拿哪条。

先准备解析记录，再绑定平台

这一步是整个方案的前置条件。不要先把域名 NS 改到 Cloudflare，也不要只在 EdgeOne 或 Pages 控制台里点击“添加自定义域名”就以为分流已经完成。正确顺序是：

顺序	要做的事	目的
1	保持域名 NS 在 DNSPod	让 DNSPod 继续拥有权威解析和线路判断权
2	在 EdgeOne 控制台创建站点/加速域名，取得 `.dnsoe4.com` 或 `.eo.dnse2.com` 接入地址	得到国内/默认线路的目标
3	在 Cloudflare Pages 取得 `*.pages.dev` 项目域名	得到境外线路的目标
4	在 DNSPod 先添加并启用国内/默认线路和境外线路的 CNAME	让不同线路的 DNS 查询能拿到对应目标
5	回到 EdgeOne、Cloudflare Pages 检查自定义域名和证书	确认平台已经接收这些 CNAME 请求
6	用国内、海外 DNS 查询器分别验证返回值	确认分流真的发生在 DNS 层

DNSPod 记录是分流的开关，平台自定义域名只是接入和证书配置。没有第 4 步，后面的平台状态即使显示“已添加”，用户也可能仍然拿到旧目标或错误证书。

临时迁移 NS 只能用于处理平台对 apex 域名的特殊校验，不能当作长期架构。迁移期间 DNSPod 的线路记录不会继续参与解析；Cloudflare 的 zone 激活后，还必须把记录完整复制过去，切回 DNSPod 后再恢复四条线路记录。

现状：主站在 EdgeOne Pages，镜像是 Cloudflare Pages

先交代博客本体。主站部署在 EdgeOne Pages，myblog 仓库 push 后 EdgeOne 的 CI 自动构建并部署到腾讯边缘节点。在控制台接入自定义域名后，EdgeOne 分配了一个 *.pages.dnsoe4.com 的 CNAME 接入地址：

xingwangzhe.fun → xingwangzhe.fun.pages.dnsoe4.com

国内解析这个 CNAME 会直接命中 EdgeOne 的大陆节点（实测 1.56.100.83，黑龙江哈尔滨联通），所以裸域国内不需要再套 CDN。

镜像在 Cloudflare Pages（staluxmyblog.pages.dev），同一份 myblog 仓库，两条 CI 各构建各的。因为内容完全一样，海外线路直接解析到镜像即可，也不用再套一层 CDN。

EdgeOne 侧配置

在 EdgeOne 控制台添加站点 xingwangzhe.fun，接入方式选「DNSPod 托管接入」——域名在 DNSPod 托管，这个模式最省事，CNAME 状态会自动校验。

创建站点时「加速区域」我选的是全球可用区。这个选择很关键，后面踩坑部分会细说。

然后添加加速域名 www.xingwangzhe.fun，源站填 staluxmyblog.pages.dev（就是 Cloudflare Pages 镜像域名，走 IP/域名回源）。EdgeOne 会分配一个 CNAME：www.xingwangzhe.fun.eo.dnse2.com。

控制台里能看到：

接入方式：DNSPod 托管接入
加速区域：全球可用区
站点级 DDoS 防护级别：标准防护
DNSPod 服务器生效状态：已生效
www.xingwangzhe.fun → www.xingwangzhe.fun.eo.dnse2.com → 源站 staluxmyblog.pages.dev

所以国内两条链路分别是：裸域 @ 直接走 EdgeOne Pages 主站（dnsoe4.com），www 走 EdgeOne 加速域名（eo.dnse2.com）回源到镜像。内容跟主站是同一份构建产物，回源到镜像不影响结果。

Cloudflare 侧：还是那个镜像

staluxmyblog.pages.dev 是 Cloudflare Pages 上的博客镜像，项目用的也是 myblog 仓库。Pages 自带全球 Anycast，海外访问本来就很快，所以海外线路不需要再套任何 CDN，直接 CNAME 到镜像就行。

之前写过的《Cloudflare Pages 自定义依赖安装实践》里有我折腾 Pages 构建的记录，这里就不展开了。

DNSPod 解析记录

最终在 DNSPod 里配了四条记录（@ 和 www 都要配，避免裸域或 www 漏掉一个）：

这四条记录要在平台接入完成后明确创建并保持启用。尤其是境外线路的 *.pages.dev CNAME：它不是“代理服务器地址”，而是 Cloudflare Pages 的静态镜像入口；DNSPod 只有在收到境外线路的 DNS 查询时，才把它返回给海外用户。国内/默认线路则返回 EdgeOne 的接入地址。先删记录、后补记录，或者只配默认线路，都会让某些地区拿到错误的站点或证书。

主机	线路	值	RecordId	状态
@	默认	`xingwangzhe.fun.pages.dnsoe4.com.`（EdgeOne Pages 主站）	2098279472	启用
@	境外	`staluxmyblog.pages.dev.`（Cloudflare Pages 镜像）	2372294422	启用
www	默认	`www.xingwangzhe.fun.eo.dnse2.com.`（EdgeOne 加速域名，回源镜像）	2372294393	启用
www	境外	`staluxmyblog.pages.dev.`（Cloudflare Pages 镜像）	2372294408	启用

注意 @ 默认走的是 EdgeOne Pages 主站（dnsoe4.com），www 默认走的是 EdgeOne 加速域名（eo.dnse2.com），两个都属于 EdgeOne，只是接入形态不一样。

验证一：DNS 视角看分流

我这台机器在代理环境里，dig 拿到的全是 fake-ip（198.18.0.x），不能用来判断真实分流。所以改用 DoH，分别指定国内和海外解析器来查。

先查 EdgeOne 的 CNAME www.xingwangzhe.fun.eo.dnse2.com：

国内视角（阿里 223.5.5.5、DNSPod doh.pub）：

1
curl -s "https://223.5.5.5/resolve?name=www.xingwangzhe.fun.eo.dnse2.com&type=A" \
2
  -H "accept: application/dns-json"
3
# → 1.56.100.83

查一下这个 IP 的归属：中国黑龙江哈尔滨，中国联通（AS4837）——这是中国大陆节点。

海外视角（Google dns.google、Cloudflare 1.1.1.1）：

1
curl -s "https://dns.google/resolve?name=www.xingwangzhe.fun.eo.dnse2.com&type=A"
2
# → 43.174.247.33 / 43.174.246.33（EdgeOne 海外节点）

同一个 CNAME，国内拿到哈尔滨联通 IP，海外拿到 EdgeOne 海外节点 IP——EdgeOne 自己在做地域选点。

再直接查域名本身的 CNAME：

国内视角：xingwangzhe.fun → xingwangzhe.fun.pages.dnsoe4.com.（EO Pages 主站）
海外视角：xingwangzhe.fun / www.xingwangzhe.fun → staluxmyblog.pages.dev.（CF Pages 镜像，解析到 172.66.47.102 / 172.66.44.154）

DNSPod 的线路分流在 DNS 层已经生效了。

验证二：itdog 测速

打开 itdog.cn 网站测速 xingwangzhe.fun，270 个监测点参与测试：

整体结果：

维度	平均耗时
全部节点	0.597s
中国电信	0.685s
中国联通	0.600s
中国移动	0.552s
华东 / 华南	0.659s / 0.589s
华中 / 华北	0.434s / 0.512s
西南 / 西北	0.569s / 0.865s

最佳节点是中国香港 0.055s。不过也有几个明显慢的点：福建厦门联通 3.497s、山东烟台电信 3.478s、内蒙古包头联通 2.541s，都集中在联通个别节点上。具体原因我没细查，可能是这些节点没命中缓存需要回源到 Cloudflare Pages 镜像，也可能是联通到 EdgeOne 某些节点的链路问题，这个坑先记着。

踩坑：加速区域不是想改就能改

折腾完以为大功告成，我又手贱想试试能不能把加速区域改成「中国大陆可用区」，用命令行直接调 API：

1
tccli teo ModifyZone --ZoneId zone-3dntktoncm6q --Area mainland

结果：

1
[TencentCloudSDKException] code:OperationDenied.PlanAndZoneAreaConflict
2
message:当前套餐不支持该加速区域。

免费版不支持单独选「中国大陆可用区」，那是付费套餐的能力。

但这里有个关键点：xingwangzhe.fun 是 ICP 备案过的（辽ICP备2024042064号-1）。所以免费版的「全球可用区」本身就包含中国大陆节点——前面查到 1.56.100.83 哈尔滨联通就是证据。

也就是说：

分流靠的是 DNSPod 线路解析，跟 EdgeOne 的「加速区域」设置关系不大。免费版选「全球可用区」，对已备案域名来说已经等于国内可用，没必要为了改成「中国大陆可用区」去升级付费套餐。

反过来提醒一句：如果域名没备案，免费版「全球可用区」不含大陆节点，国内体验会差很多。想走这条路线，备案是前提，这也是我一直把 ICP 备案放在心上的原因（相关记录见《阿里云备案记录》、《辽宁省个人公安联网备案记录》）。

总结

现在的架构长这样：

国内用户 → DNSPod 默认线路 → 腾讯 EdgeOne（裸域走 EdgeOne Pages 主站、www 走加速域名，都含中国大陆节点）
海外用户 → DNSPod 境外线路 → Cloudflare Pages 镜像（staluxmyblog.pages.dev）

成本：EdgeOne 免费版 + Cloudflare Pages 免费版，都是 0 元。

一句话总结：先在 DNSPod 准备并启用两组线路 CNAME，再让 EdgeOne 和 Cloudflare Pages 分别接收这些目标；主站 EdgeOne + 镜像 Cloudflare，靠 DNSPod 线路分流 + EdgeOne「全球可用区」（已备案）+ Cloudflare Pages 海外兜底，海内外分流才算完成。它的核心是 DNS 层的线路判断，不是代理服务器。