最近给博客接入 Cloudflare for SaaS 时，我顺手把“优选域名加速”的链路也整理了一遍。这个方案的核心不是把 Cloudflare 绕开，而是把用户入口从 Cloudflare 自动分配的边缘节点，改成一个你测试后更稳定的 Cloudflare 入口，再通过 Cloudflare for SaaS 把请求转回自己的源站。

这里的 SaaS 指的是 Cloudflare for SaaS / Custom Hostnames，不是前端里的 Sass。

先说结论

如果你只是想让一个静态博客通过优选入口访问，推荐的最小结构是：

  • origin.example.com：A / AAAA / CNAME 到你的源站，橙云，作为 Cloudflare for SaaS 的 fallback origin。
  • cdn.example.com：CNAME 到你测试出来的优选目标，灰云。
  • site.example.com：CNAME 到 cdn.example.com，灰云。
  • Cloudflare for SaaS：添加 Custom Hostname site.example.com。
  • Origin：优先使用 Fallback Origin = origin.example.com，不要一上来就给 site.example.com 单独填 Custom Origin。

以下使用保留示例域名说明结构：

origin.example.com  A      203.0.113.10       Proxied / 橙云
cdn.example.com   CNAME  best-cf-entry.example.net   DNS only / 灰云
site.example.com  CNAME  cdn.example.com        DNS only / 灰云

其中 best-cf-entry.example.net 是占位写法。实际使用时，可以替换成自己实测可用、可信且稳定的 Cloudflare 优选 CNAME 目标，例如公开汇总站里常见的 cf.090227.xyz 或它的自定义前缀泛域名。

cf.090227.xyz 是什么？

cf.090227.xyz 是一个社区维护的 Cloudflare 优选域名汇总站。它的页面会汇总一些可用的 Cloudflare 优选域名、支持端口和运营商线路入口，并说明 *.cf.090227.xyz 是泛域名：例如下面这些写法理论上可以指向同一套优选解析逻辑：

cf.090227.xyz
site.cf.090227.xyz
myblog.cf.090227.xyz

它还提供了按运营商区分的 API 入口，例如电信、联通、移动对应的优选 IP 查询接口。对于个人站点来说，你可以把它理解为“第三方帮你持续筛选 Cloudflare 入口”的公共服务。

不过这类服务不是 Cloudflare 官方 SLA 的一部分，使用前建议自己验证：

  • 解析结果是否仍然落在 Cloudflare 相关网络。
  • 你所在地区和运营商访问是否真的更快。
  • HTTPS 访问是否稳定。
  • 服务方是否有更新说明和免责声明。

本文后续仍然使用 best-cf-entry.example.net 作为占位目标，避免把某个第三方域名写死成唯一推荐。你实际配置时，可以替换为 cf.090227.xyz、your-prefix.cf.090227.xyz 或其它你测试后更合适的优选 CNAME。

这套方案到底在加速什么？

普通 Cloudflare 托管时，请求路径通常是：

直接回源与 Cloudflare for SaaS 优选入口对比

Cloudflare 本身会根据网络情况把用户调度到某个边缘节点。但在部分地区，自动调度到的入口不一定是你体感最好的那个。所谓“优选域名”，本质上是人为指定一个更合适的 Cloudflare 入口，让访客先走到那里。

再通过 Cloudflare for SaaS，Cloudflare 会把 site.example.com 识别为一个 Custom Hostname，并按你配置的 fallback origin 或 custom origin 回源。

所以它优化的是这一段：

访客 → Cloudflare 入口

不是这一段：

Cloudflare → 你的源站

如果你的源站本身在海外，而用户也在海外，这个方案未必有明显提升；如果你的用户所在网络到默认 Cloudflare 入口不稳定，优选入口才可能有价值。

三个域名各自负责什么

这套配置容易混乱，是因为我们会同时使用三个域名：

Cloudflare for SaaS 组件关系

origin.example.com：回源域名

这个域名指向你的真实源站，并且必须在 Cloudflare DNS 里开启小黄云。

Cloudflare 文档要求：Cloudflare for SaaS 的 fallback origin 或 custom origin 必须是同账号 DNS 中一个有效的、已代理的 A / AAAA / CNAME 记录，不能直接填 IP。

因此不要在 Cloudflare for SaaS 里直接填：

203.0.113.10

而是应该填：

origin.example.com

cdn.example.com：优选入口承接域名

这个域名只是用来 CNAME 到你的优选目标。它要保持灰云，否则 Cloudflare 会先把它代理掉，你的优选 CNAME 链就不再按预期工作。

cdn.example.com CNAME your-best-cf-target.example.net  DNS only

site.example.com：用户真正访问的域名

用户最终访问的是 site.example.com。它也保持灰云，CNAME 到 cdn.example.com。

site.example.com CNAME cdn.example.com  DNS only

当请求进入 Cloudflare 后，Cloudflare for SaaS 会根据 Custom Hostname 配置识别 site.example.com，再转发到你配置的 origin。

推荐配置路径

第一步：准备回源域名

在 Cloudflare DNS 中添加：

Type: A
Name: origin
Value: 你的源站 IP
Proxy status: Proxied / 橙云

如果你的源站是 Caddy，建议源站站点至少能处理最终访问域名：

site.example.com {
    root * /var/www/blog
    encode gzip zstd
    file_server
}

如果你后面坚持用 Custom Origin = origin.example.com，那源站还需要同时接受 origin.example.com，原因后面会讲。

第二步：设置 Cloudflare for SaaS 的 Fallback Origin

进入 Cloudflare Dashboard：

SSL/TLS → Custom Hostnames → Fallback Origin

填写：

origin.example.com

等待状态变成 Active。

这一步的意义是告诉 Cloudflare：Custom Hostname 没有单独指定 origin 时，默认回源到 origin.example.com。

第三步：创建优选 CNAME 链

在 DNS 里添加：

cdn.example.com   CNAME   your-best-cf-target.example.net   DNS only
site.example.com  CNAME   cdn.example.com                   DNS only

这里最容易错的是小黄云状态：

  • origin.example.com：橙云。
  • cdn.example.com：灰云。
  • site.example.com：灰云。

第四步：添加 Custom Hostname

进入：

SSL/TLS → Custom Hostnames → Add Custom Hostname

填写：

Hostname: site.example.com

如果你已经配置了 Fallback Origin，一般可以先不填 Custom Origin Server，让它走默认 fallback origin。

等待两个状态都变成可用：

  • Hostname status：Active
  • Certificate status：Active

Cloudflare for SaaS 的证书签发和 hostname 激活是两条流程。不要只看浏览器能不能握手，Dashboard / API 里的状态才是更可靠的判断依据。

第五步：检查 SSL 模式

不要使用 Flexible。推荐至少使用 Full，理想情况下使用 Full strict。

如果 Full strict 不通，通常不是“优选域名”本身的问题，而是 Cloudflare 回源时的 SNI / Host / 源站证书没有对上。

Custom Origin 的 SNI 陷阱

很多人会在添加 Custom Hostname 时顺手填：

Custom Origin Server: origin.example.com

这不是一定错，但要知道它会改变回源 SNI 行为。

Custom Origin 的 Host 与 SNI 陷阱

Cloudflare 文档里说明：

  • 使用默认 fallback origin 时，回源 Host 和 SNI 通常都是原始 custom hostname，也就是 site.example.com。
  • 使用 custom origin server 时，回源 Host 仍然是 site.example.com，但 SNI 会变成 custom origin，也就是 origin.example.com。

这会导致一个典型问题：

Host: site.example.com
SNI:  origin.example.com

如果你的源站只为 site.example.com 配了证书和站点，Full strict 可能失败。

解决方法有三个：

  1. 最简单：不要给这个 hostname 单独设置 Custom Origin，让它走 Fallback Origin。
  2. 源站同时配置 site.example.com 和 origin.example.com 的证书与站点。
  3. 如果你的 Cloudflare 计划支持，使用 SNI rewrite 或 Origin Rule 覆盖 SNI。

我更推荐第一种，除非你真的需要不同 custom hostname 回到不同源站。

Caddy 示例配置

如果你使用推荐的 fallback origin 模式，Caddy 可以只配置最终访问域名：

site.example.com {
    root * /var/www/blog
    encode gzip zstd
    file_server
}

如果你已经使用了 Custom Origin Server = origin.example.com，建议这样配，确保回源 SNI 为 origin.example.com 时也能完成 TLS：

site.example.com, origin.example.com {
    root * /var/www/blog
    encode gzip zstd
    file_server
}

改完后记得验证和 reload：

sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy

如何验证是否成功

DNS 链检查

dig +short site.example.com CNAME
dig +short cdn.example.com CNAME
dig +short your-best-cf-target.example.net

你应该能看到类似：

site.example.com → cdn.example.com → 优选目标 → Cloudflare 入口 IP

HTTP 访问检查

curl -I https://site.example.com/

如果正常，应该看到：

HTTP/2 200
server: cloudflare

源站回源模拟

如果你使用了 Custom Origin Server，可以在源站本机模拟：

curl -k -I --resolve origin.example.com:443:127.0.0.1 https://origin.example.com/ -H 'Host: site.example.com'

能返回 200，说明源站能够处理 SNI = origin.example.com 且 Host = site.example.com 的组合。

常见错误

1. site.example.com 开了小黄云

如果 site.example.com 开了小黄云，DNS 查询不会按你的 CNAME 链去走优选目标，而是直接由当前 Cloudflare zone 接管。

这通常会让“优选入口”失效。

2. origin.example.com 没开小黄云

Cloudflare for SaaS 要求 fallback origin / custom origin 是已代理的 DNS 记录。origin.example.com 如果是灰云，Fallback Origin 很可能无法激活。

3. 直接在 origin 里填 IP

不支持。要先在 DNS 里创建一个橙云 hostname，再把这个 hostname 填到 Cloudflare for SaaS。

4. 使用 Custom Origin 后 Full strict 失败

优先检查 Host / SNI / 证书是否匹配。Custom Origin 的默认行为会让 SNI 变成 custom origin hostname，而 Host 保持原始 custom hostname。

5. 优选目标失效

优选域名通常不是 Cloudflare 官方承诺的稳定能力。目标域名可能变更、失效、被污染或路由变差。建议保留一个可以快速回退的普通 Cloudflare 配置。

这套方案适合谁

适合：

  • 静态博客、个人站、小型服务。
  • 源站本身可通过 Cloudflare 正常访问。
  • 主要瓶颈是本地网络到默认 Cloudflare 入口不稳定。
  • 你能接受维护 DNS 链和 Cloudflare for SaaS 状态。

不适合：

  • 对稳定性要求极高、不能接受非官方优选入口变化的业务。
  • 源站 TLS / SNI / Host 配置不清楚的复杂系统。
  • 需要多地域、健康检查、自动故障切换的正式生产业务。那应该考虑 Cloudflare Load Balancing、Tunnel 或更标准的多源架构。

总结

Cloudflare for SaaS 优选域名加速的关键不是“魔法加速”，而是拆清楚三件事：

  1. 访问域名如何通过灰云 CNAME 走到优选入口。
  2. Cloudflare for SaaS 如何识别 Custom Hostname。
  3. Cloudflare 如何通过 fallback origin 或 custom origin 回到源站。

只要记住这条原则，配置就不容易乱：

对外入口保持灰云，回源入口保持橙云；能用 Fallback Origin，就先别急着用 Custom Origin。