把域名交给 Cloudflare 管理,不等于把网站文件迁到了 Cloudflare,也不保证网页一定更快。DNS 决定域名解析到哪里,网站请求实际经过哪条路径,还要看代理状态和部署方式。

例如,同一个根域名下,博客可以继续放在原来的云服务上,家中服务器的网站通过 Tunnel 发布,数据库管理则只走私有网络。它们没有必要共用同一种接入方式。

删掉旧解析记录,不等于切换了 DNS 服务商

域名注册商记录着这个域名使用哪组权威 DNS 服务器。以常见的 Cloudflare Full setup 为例,需要在注册商处把 Nameserver 改成 Cloudflare 分配的值。

原来使用 DNSPod 时,仅关闭 DNSPod 的记录,不会改变注册商的 Nameserver。记录迁移和权威服务器切换是两步,顺序应当是先准备新记录,再切换委派。Cloudflare Full setup 步骤

可以按下面的顺序操作:

  1. 在 Cloudflare 添加根域名,例如 example.com。
  2. 对照原配置补齐仍在使用的 A、AAAA、CNAME、MX、TXT 等记录,不能只依赖自动扫描。
  3. 如果启用了 DNSSEC,按迁移指引处理旧 DS 记录,避免新权威服务器与旧签名信息不匹配。
  4. 到购买域名的注册商,修改“DNS 服务器/Nameserver”,填写 Cloudflare 分配的完整名称。
  5. 等待域名激活,检查网站、邮件和其他仍需使用的域名功能,确认后再考虑清理旧配置。

不要在普通 DNS 记录列表中添加两条 NS 记录,代替注册商层面的切换。DNSSEC 迁移则先按官方要求移除旧 DS,接管后再启用 Cloudflare DNSSEC,并将新 DS 配回注册商。

在终端检查:

dig NS example.com +short
dig app.example.com A +short
dig app.example.com AAAA +short

替换域名后,NS 应逐渐反映新的权威服务器。递归 DNS 可能仍有缓存,一次查询不能代表所有网络都已经切换。如果出现 SERVFAIL,应检查 DNSSEC 与 DS 是否匹配,不能通过反复添加同名 A 记录解决。

灰云和橙云改变了什么

Cloudflare 中,支持代理的 DNS 记录可以选择“仅 DNS”或“已代理”,通常分别显示为灰云和橙云。

状态网站请求路径浏览器连接到谁
仅 DNS,灰云浏览器 → 公网源站或原托管服务解析结果指向的服务
已代理,橙云浏览器 → Cloudflare → 源站Cloudflare 边缘入口

灰云下,Cloudflare 提供解析,不负责代理该网站的 HTTP/HTTPS。橙云下,Cloudflare 进入请求路径,浏览器入口和回源连接分别处理 HTTPS;入口有证书,不代表源站的 HTTPS 配置也自动正确。Cloudflare 代理状态

因此,灰云下通常需要由源站或托管平台提供 HTTPS;橙云也不能用来掩盖源站协议、证书或 Host 配置错误。

代理记录常返回 Cloudflare 的边缘 IP,CNAME 也可能被展平,所以 dig CNAME 没显示原目标,不一定是记录丢失。原始目标应回控制台核对。

根据服务的位置选择记录

服务位置常见配置是否需要家里的 cloudflared
有公网 IP 的服务器A 指向 IPv4,必要时 AAAA 指向 IPv6不需要
提供接入域名的托管平台CNAME 指向平台指定目标不需要
无公网入口的家庭服务器Tunnel 应用路由、关联 DNS 记录和在线连接器需要
仅自己管理的数据库私有网络配合 SSH 转发不需要

对已有托管服务,应先按平台要求绑定自定义域名,再设置它提供的 CNAME。仅添加解析记录,不保证平台已经接受该域名,也不保证证书已签发。

Tunnel 则多了一层连接器:DNS 把请求交给某个 Tunnel,在线的 cloudflared 再把请求送到本地服务。不能只添加一条 CNAME,就期待它自动穿透家庭网络。完整操作见 用 Cloudflare Tunnel 发布 Docker 容器网站。

怎样比较访问速度

“解析快”和“页面快”不是同一个指标。即使 DNS 查询只花很短时间,后面的连接、TLS、回源、应用计算和资源下载仍可能慢。

在实际访问者的网络中执行,替换 URL:

curl -sS -o /dev/null \
  -w 'HTTP: %{http_code}\nDNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n' \
  https://app.example.com/

先在浏览器或用 curl -i 确认状态码和响应内容正确。快速返回的错误页、登录跳转和正常页面不能直接比较;上面的命令没有加 -L,遇到跳转时测的是当前这一次响应。

这些时间大多从请求开始累计:

指标观察的时间点
time_namelookup名称解析完成
time_connect与目标或代理的连接建立完成
time_appconnectTLS 等应用层握手完成
time_starttransfer开始收到响应数据,即 TTFB
time_total这次传输结束

不能把各项直接相加。简单 HTTPS 请求中,可以通过相邻指标的差值粗看某一阶段;有代理、连接复用等条件时,要结合实际链路解释。TTFB 也包含网络往返和服务端等待,不能直接等同于后端计算时间。curl 时间指标定义

同一网络、同一 URL 至少测 5 次,记录状态和内容一致的结果,再比较中位数。然后换实际用户常用的网络测试。浏览器 Network 面板用来继续区分:主文档慢、静态资源慢,还是某个 API 慢。

对 AI 聊天还要单独测首个输出和完整回答耗时。首页的 curl 请求既没有测整个页面,也没有测模型生成过程。

为什么不能只看 DNS 服务商的名字

橙云可能通过缓存减少回源,也会让请求经过 Cloudflare 的网络;最终速度取决于访问网络、源站位置、缓存命中和应用行为。Cloudflare 的全球网络与专门的 China Network 也不能混为一谈。Cloudflare China Network 说明

对于不缓存的动态请求,家庭上行带宽、Tunnel 链路和模型供应商响应仍然会影响速度。这里没有 Cloudflare 与 DNSPod 在同一网络下的对照测速数据,因此不能据此给出哪一家更快的实测结论。

需要比较代理开关时,使用能分别正确处理域名和 HTTPS 的测试入口。正在使用的 Tunnel 域名不能简单改成灰云,当作直接访问家庭服务器的对照方案。