4.1 自定义域和 Workers 路由到底有何区别？#

简单来说，它们的区别在于 “控制权的归属” 和 “DNS 记录的绑定方式” ：

• 自定义域 (Custom Domains) —— “全包揽的硬绑定” 当你在 Worker 中添加自定义域时，Cloudflare 会接管一切：它会为你自动申请 SSL 证书，并强制在你的 DNS 面板中生成一条关联该 Worker 的专属 DNS 记录。 然而，这条由系统自动生成的 DNS 记录是被强行锁死为小黄云（已代理）状态的。你既无法修改它的目标地址，也无法将其关闭为灰云。既然无法将其修改为灰云并 CNAME 到我们的中转节点，这条路在优选架构下自然就被彻底堵死了。
• Workers 路由 (Workers Routes) —— “同 Zone 内部的软拦截” 与自定义域的“硬绑定”不同，路由功能本质上是一个部署在 CF 边缘节点内部的拦截器。它本身并不负责创建或管理 DNS 记录，它的逻辑仅仅是：“只要有流量进入了这个 Zone（区域），且请求的 URL 匹配我设定的规则（例如 api123.ybjun.com/*），我就把流量劫持给 Worker 处理”。 正因为路由不干涉 DNS，我们获得了完全的自由。我们可以在 DNS 面板中手动创建一条 api123 的 CNAME 记录，将其设为灰云（仅 DNS） 并指向 cdn.ybjun.com。

总结：自定义域会锁死 DNS 导致无法优选，而 Workers 路由则将 DNS 解析权完全交还给我们。因此，在本站的 API 优选方案中，我们不适用自定义域，采用 “手动 CNAME + Workers 路由” 的解决方法。

4.2 操作步骤#

首先进入目标 Worker。假设这个 Worker 计划继续使用之前的自定义域api123.ybjun.com作为优选加速域名。

点击设置，在域和路由栏目下，删除之前的自定义域api123.ybjun.com，然后添加，选择路由。

区域选择主域名ybjun.com，在路由处填写优选加速域名 + /*，这里就是api123.ybjun.com/*，点击添加路由。

IMPORTANT

这里注意，优选加速域名后面必须要填上/*！/*是一个通配符，代表此域名下的所有路径，这里填上/*，就可以确保 Cloudflare 把所有对api123ybjun.com及其下任何路径的请求都转发给 Worker。当然一般而言，如果这里填的内容没有以/*结尾，CF 就会拦截并让你补上。

接着，再回到ybjun.com的 DNS 记录页，添加一条 CNAME 记录，把 api123 指向 cdn.ybjun.com，关闭小黄云，操作完毕！

4.3 结果对比#

下面，我们用一种最直观的方式来感受一下 Worker API 在优选加速前后的访问差距，那就是使用 itdog.cn 提供的 TCPing 工具。

下图是优选加速前的本站评论区 API 全国访问结果：

下图是优选加速后的本站评论区 API 全国访问结果：

优选效果，一目了然！

5.1 失败尝试1：被停用的自定义域#

既然 Pages 必须使用自定义域，那我们按照 Worker 的逻辑，“偷梁换柱”手动接管其自定义域的解析层，行不行？所以博主做了如下步骤的尝试：

1. 在 Pages 项目中正常绑定自定义域 www.ybjun.com。
2. 待证书和 DNS 生效后，前往 DNS 记录界面，手动将这条由 Pages 生成的记录改为灰云（仅 DNS），并手动把 CNAME 的目标由 *.pages.dev 修改为我们的优选 cdn.ybjun.com。

刚修改完确实能短时间起效，但只要 GitHub 仓库一有新的 Commit 触发 Pages 的自动构建，或仅仅是过一段时间，www.ybjun.com 的自定义域状态就会变成已停用。浏览器访问时报错Error 1000 DNS points to prohibited IP。

原因分析： Cloudflare Pages 有一套极其严格的 CI/CD 域名校验机制。每当项目重新编译部署，系统都会扫描你的 DNS 记录，确保自定义域依然指向 *.pages.dev。一旦发现 DNS 记录对不上，Pages 为了安全起见会认为该域名已失效，从而直接停用。

5.2 失败尝试2：使用 CF for SaaS 的两头堵#

上面的踩坑证明了在同一个域名下强行修改 Pages 的 DNS记录是行不通的。于是博主决定试试网上通用的、都在说的 Cloudflare for SaaS (自定义主机名)，利用一个辅助域名ybjtest.com作为中转，绕过 Pages 的检测。

在详细复盘之前，有必要先简单提一嘴被目前各大网上教程奉为圭臬的 Cloudflare for SaaS（自定义主机名）到底是个什么东西。本质上，这是 CF 为 SaaS 企业提供的一项服务，允许外部客户将自己的域名接入到企业的主体服务中，并由 CF 统一签发证书和路由兜底。

例如，某电商平台shopping.com为在平台注册的店家提供“自定义主机名”服务。这样，一个叫mobilefan的手机卖家就可以直接将自己的网站mobilefan.com直接纳入shopping.com提供的一系列网络服务中，可以统一签发证书，可以参与路由规则，等等，而不是必须使用长长的三级域名mobilefan.shopping.com。

但国内的网友们发现并利用了其中的一个机制漏洞：一旦你在 SaaS 中添加并验证了某个域名，CF 的全球边缘节点就会为该域名发放一张“特许通行证”。有了这张通行证，你就可以将该域名的 DNS 强制 CNAME 到任何一个优选节点上。当流量抵达优选边缘节点时，由于有 SaaS 登记在册，CF 不会将其判定为非法请求而拦截（不报 Error 1001），而是顺着“回退源”放行。

正因如此，利用 SaaS 的这个机制“骗”过规则层，几乎成了近年来全网 CF 优选教程里的万金油标配。

具体来说，博主是这么做的：

1. 设置回退源。 为主站 Page 绑定一个ybjtest.com下的三级域名ybjun.ybjtest.com作为自定义域，这个域名将作为回退源使用。
2. 添加辅助域名的优选源中转。 为ybjtest.com添加一条名为cdn 的 CNAME 记录，指向*.cf.090227.xyz。
3. 开启 CF for SaaS。 在ybjtest.com 控制台左侧打开 SSL/TLS -> 自定义主机名，先添加回退源ybjun.ybjtest.com，再按照要求，添加自定义主机名www.ybjun.com进去，并为www.ybjun.com添加相应的证书 TXT 记录和主机验证 TXT 记录，使得验证通过，自定义主机名可以正常使用。

接下来需要为www.ybjun.com添加灰云的优选 CNAME 记录，但问题就这么来了， “一根筋”就此变为“两头堵” 。

• 把CNAME目标指向cdn.ybjtest.com，浏览器访问会Error 522。原因是虽然 SaaS 确实被触发了，但回退源ybjun.ybjtest.com是一个 Pages 域名。CF 的安全机制中，SaaS 回源到 Pages 项目极其容易触发 522（连接超时），因为 Pages 的边缘节点拒绝接受带有被篡改的 Host 头的异常回源请求，直接把连接掐断了。
• 把CNAME目标指向cdn.ybjun.com，浏览器访问会Error 1000。原因是在 CF 的底层路由协议中：原生 Zone 内的路由优先级永远大于 SaaS 自定义主机名。当请求 www.ybjun.com 到达优选节点时，节点一看：“哦，ybjun.com 就在系统里，我直接去查它的原生 DNS 表。” 节点根本就懒得去查ybjtest.com 里的 SaaS 名单。结果节点在 ybjun.com 里一看，www 是个灰云，而且没有绑 Worker 路由，也没有绑 Pages，直接判定为“非法回环解析”，扔回一个无情的 Error 1000。

由上可见，网上广为流传的 Cloudflare for SaaS 方案，可能主要还是适用于 VPS 等其它部署方案，并不适用于 Pages 项目。Pages 的自定义域是“动不得”的，而 SaaS 路由在同 Zone 下又是“进不来”的。面对这种左右为难的局面，博主最后只能尝试一种兜底的“曲线救国”方案——跳出 Pages 的框架，做一个简单的 Worker 代理去转发 Page 的流量。

5.3 最终方案：Worker 桥接代理#

既然 Pages 这么难伺候，我们就做一个小 Worker 桥接一下，毕竟由第三章可知，Worker 的优选还是很简单的。所以我们的思路就是，让优选节点去直接这个 Worker，让 Worker 在 CF 内部直接拉取源站数据和转发流量，免除一切烦恼。

新建一个 Worker（例如 pages-proxy），填入以下代码：

1
export default {
2
  async fetch(request) {
3
    const url = new URL(request.url);
4
    url.hostname = 'ybjun.com';     // 替换成你实际的 pages.dev 域名或自定义域
5
    const newRequest = new Request(url, request);
6
    return fetch(newRequest);
7
  }
8
};

TIP

由于博主想实现分流和对比，因此改掉了之前 ybjun.com 展平 CNAME 到 www.ybjun.com 的设定，直接将 ybjun.com 绑定为了 Page 的自定义域，作为未优选加速的全球访问渠道。中国大陆用户访问优选加速的www.ybjun.com。 由于*.pages.dev在中国大陆访问可能受限制，因此博主在上面 Worker.js 中填入了自定义域名ybjun.com以避免可能出现的其他问题，博主个人也比较推荐大家这么写。

接着重复上文 Workers 优选的步骤：DNS 设www.ybjun.com灰云 CNAME 指向cdn.ybjun.com，并在 Worker 里添加 www.ybjun.com/* 的路由。主站至此完美起飞！

6.1 “消失”的证书#

这是本站优化过程中遇到的第一个“拦路虎”，也是最具隐蔽性的坑。

现象描述： 当博主尝试对 pic.api1.ybjun.com 进行优选后，浏览器直接报错：ERR_SSL_VERSION_OR_CIPHER_MISMATCH。无论如何刷新、清除缓存，甚至重新申请证书都无济于事。

原因分析： 这是由 Cloudflare Universal SSL（通用证书）的保护范围决定的。CF 为免费版用户提供的通配符证书仅支持到三级域名（即 *.ybjun.com 和 ybjun.com）。一旦你的域名深度达到了四级（如 pic.api1.ybjun.com），它就超出了通用证书的覆盖范围。特别是关闭小黄云的时候，边缘节点将无法提供有效证书，导致 TLS 握手瞬间崩溃。

不过有个例外，当我们将四级域名直接绑定为 Workers 等内容的自定义域，CF 也会额外为这些域名申请证书保护。具体可以去 CF 域名控制台的 SSL/TLS -> 边缘证书 中查看。

解决过程：“全栈降维”。博主将所有涉及到的四级域名全部重构为三级域名，这就要对前端代码库和数据库内相关内容进行替换。前端代码库让 Agent 直接操作即可，为了处理 D1 数据库中成百上千条历史链接，博主配合 SQL 的 REPLACE 函数完成了自动化替换。

6.2 虚惊一场#

现象描述： 在优选工作接近尾声时，DNS 列表中突然跳出了满屏的黄色感叹号警告：“本记录可能会暴露 api3.ybjun.com 的源站地址…”。

原因分析： 这是 Cloudflare 的源站保护误报。当博主在配置优选加速域名时，如果不小心开启了某个优选加速域名的小黄云，而这个域名又指向了一个已经设为灰云的优选中转（cdn.ybjun.com），CF 就会认为你试图隐藏源站，却又通过其他记录泄露了它。

解决过程：“保持一致性”。在优选架构中，既然我们要接管解析层，那么所有参与优选的三级子域名都必须统一保持灰云状态。将这些记录全部修正为灰云后，警告自动消失。所以，添加优选加速域名记录时记得关掉小黄云！