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 请求拿到不同的结果。

思路很简单:

国内/默认线路境外线路Cloudflare Pages 镜像staluxmyblog.pages.devDNSPod 按线路解析腾讯 EdgeOnePages 主站 / 加速域名用户

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

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

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

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 的接入地址。先删记录、后补记录,或者只配默认线路,都会让某些地区拿到错误的站点或证书。

注意 @ 默认走的是 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):

curl -s "https://223.5.5.5/resolve?name=www.xingwangzhe.fun.eo.dnse2.com&type=A" \

-H "accept: application/dns-json"

# → 1.56.100.83

查一下这个 IP 的归属:中国黑龙江哈尔滨,中国联通(AS4837)——这是中国大陆节点。

  • 海外视角(Google dns.google、Cloudflare 1.1.1.1):

curl -s "https://dns.google/resolve?name=www.xingwangzhe.fun.eo.dnse2.com&type=A"

# → 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.055s。不过也有几个明显慢的点:福建厦门联通 3.497s、山东烟台电信 3.478s、内蒙古包头联通 2.541s,都集中在联通个别节点上。具体原因我没细查,可能是这些节点没命中缓存需要回源到 Cloudflare Pages 镜像,也可能是联通到 EdgeOne 某些节点的链路问题,这个坑先记着。

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

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

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

结果:

[TencentCloudSDKException] code:OperationDenied.PlanAndZoneAreaConflict

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 层的线路判断,不是代理服务器。

Creative Commons