现象：DNS 明明配对了，平台就是说不对

给 IPFS 站点绑自定义域名，在 4everland 控制台填好域名，按要求添加 CNAME 记录：

1
2
类型    名称    内容
CNAME   blog    23feacba8df54bc88514.cname.ddnsweb3.com

保存，点「Verify」。等几分钟，状态一直是：

1
2
blog.demohappy.top
Invalid Configuration

反复删了重建、换浏览器、等了一小时、换了一台机器查 DNS——所有检查都显示 CNAME 是对的：

1
2
$ nslookup -type=CNAME blog.demohappy.top
blog.demohappy.top  canonical name = 23feacba8df54bc88514.cname.ddnsweb3.com.

记录确实存在，值也对。但平台就是不认。

根因：橙云把 CNAME 变成了 A 记录

问题出在 Cloudflare 的代理状态上。

Cloudflare 的 DNS 记录有一个云朵开关：

  • 灰云（DNS only）：Cloudflare 只做解析，查询 CNAME 会老老实实返回目标主机名
  • 橙云（Proxied）：Cloudflare 接管流量，对外表现为自己的 Anycast IP——查询 CNAME 时不再返回目标主机名，而是返回 Cloudflare 的 A 记录

验证方（4everland / Vercel / Netlify / 各类 SaaS 的域名验证器）做的事情是：发起 DNS 查询，看 blog.yourdomain.com 的 CNAME 是否等于它给的那个目标值。

橙云状态下，它查到的是 104.21.x.x、172.67.x.x 这类 Cloudflare IP，CNAME 链被隐藏了。验证逻辑只能得出结论：这条记录指向的不是我们。

于是报 Invalid Configuration，而且永远不会自己好——因为 DNS 从平台的视角看一直是错的。

修复流程

第一步：把云朵点灰

Cloudflare 控制台 → DNS → 找到那条 CNAME → 点击橙色的云朵图标，变成灰色（显示 DNS only）。

第二步：等待生效

改完之后不要立刻点验证。Cloudflare 的边缘节点缓存 TTL 通常是 30 秒到 5 分钟，保守等 5 分钟。可以用这个命令确认已经返回真实 CNAME：

1
2
# 加 +short 看简洁结果
nslookup -type=CNAME blog.demohappy.top 1.1.1.1

如果返回的还是 IP 而不是主机名，说明还没切过来，继续等。

第三步：重新验证

回平台点 Verify。这次应该立刻通过，状态变成 Active 或 Valid Configuration。

第四步：验证通过后再点回橙云

这一步很关键，而且顺序不能反。先验证通过，再开代理。

很多人（包括我）会觉得「既然灰云能通过，那我干脆一直灰云」——技术上可行，但会失去 Cloudflare 的 CDN 缓存、WAF、DDoS 防护、自动 HTTPS 这些能力。正确做法是验证通过、平台侧已经把域名标记为可信之后，再切回橙云。

切回橙云不会影响已经完成的验证——因为验证是一次性的，平台记住了结果。

另一个容易误判的报错

绑定过程中还遇到另一种表现：直接访问域名，返回的不是站点，而是一个奇怪的 CSS 报错：

1
BunnyCDN ... unconfigured.css

这个信息容易被理解成「站点配置坏了」或者「代码有问题」。实际上它的含义很明确：CDN 收到了这个主机名的请求，但没有任何站点绑定在这个主机名上。

换句话说，请求已经到达了 4everland 背后的 CDN（这个平台底层用的是 bunny.net），但主机名没有在平台侧完成绑定——所以 CDN 不知道该给谁，返回一个默认的「未配置」页面。

判定方式很简单：

现象 含义 该查哪
Invalid Configuration（控制台） 平台认为 DNS 没指向它 DNS 记录 + 代理状态
访问返回 BunnyCDN ... unconfigured.css 请求到了 CDN，但主机名没绑上 平台侧的域名绑定状态
访问返回 404 / 空白页 主机名绑上了，但内容没部署 构建产物 / 部署状态

三者是不同阶段的问题，别混着排查。

这个坑的通用性

「平台验证 CNAME 所有权」这个模式，几乎所有静态托管和 SaaS 平台都有：Vercel、Netlify、Render、Railway、Cloudflare Pages 自定义域、各种企业版 SaaS 的域名验证。

所以这条经验可以抽成一句通用规则：

任何需要验证 DNS 所有权的场景，先把 Cloudflare 代理关掉（灰云），验证通过再开回来。

同源的问题还有几个变体：

  • 用 Cloudflare 的 CNAME Flattening 时，根域名（@）的 CNAME 会被展平成 A 记录，某些验证器同样会失败。此时改用 TXT 记录验证（如果平台支持）
  • 平台要求 TXT 验证但你在 CF 里加了代理——TXT 记录不受云朵影响，这类验证可以开着橙云
  • 验证通过了但访问 522/521——橙云开着、源站（或在 IPFS 场景下的 CDN）拒绝 Cloudflare 的回源连接，这和域名验证是两回事

排查顺序收口

遇到自定义域名绑不上的问题，按这个顺序查，能省掉大部分瞎试：

  1. DNS 记录本身对不对（nslookup -type=CNAME 看值）
  2. 是不是被代理隐藏了（返回 IP 而不是主机名 → 关橙云）
  3. 平台侧是否已完成绑定（unconfigured.css → 还没绑）
  4. 内容是否已部署（404 → 绑了但没内容）

第 2 步是最容易被跳过的，因为 DNS 检查工具显示「记录存在」就让人放心了——但「存在」和「能被验证方看见」是两件事。

这次绑定域名前后折腾了一下午，完整过程记在 记录一次博客主域名迁移的全过程。迁移完成后的 SEO 收尾清单见 Hexo 换域名后 canonical 和 sitemap 还指着旧域。