最近帮几个朋友把域名 DNS 从注册商迁到了 Cloudflare，遇到的情况各不相同。有的是为了用 Cloudflare 的免费 CDN 加速，有的是为了做安全防护，还有的只是单纯想统一管理不同域名的 DNS。这里把迁移过程里最常踩的坑和判断逻辑整理出来，供参考。

先明确迁移范围：是换 DNS 托管，还是换注册商

很多人上来就问“怎么把域名转给 Cloudflare”，但实际分两种情况：一种是只把 DNS 解析权交给 Cloudflare（DNS 托管），域名仍在原注册商管理；另一种是把整个域名注册商也转到 Cloudflare（即域名转移）。对于大多数普通场景，只做 DNS 托管就可以了——能获得解析加速、CDN 和 WAF 能力，且不影响续费和注册商。

判断自己属于哪种，可以先用 whois 或 DNS 工具确认当前 NS 记录指向谁。素材1里提到：确认域名当前 DNS 服务商是首要步骤。大多数域名注册商默认提供 DNS 托管，但也可能使用第三方如 DNSPod、阿里云 DNS 等。若服务商支持 NS 记录修改，即可迁移；若需转移注册商，则需先解锁域名并获取授权码。对于纯 DNS 托管迁移，无需转移注册商，仅更改 NS 记录即可。 这一点非常关键——不少人在操作前没搞清楚，误以为需要把域名转走，结果多付了转移费用和等待时间。

迁移前的准备工作：备份、降 TTL、关 DNSSEC

正式操作前，建议在旧 DNS 管理后台导出全部 DNS 记录，或者至少截图保存。素材4提到了两个重要风险：切换 NS 后，旧 DNS 服务商的记录将立即失效，因此务必先备份原有记录。为加快切换，在修改前将原记录的 TTL 值降至 300 秒。若网站使用 SSL 证书，需在 Cloudflare 的 SSL/TLS 设置中选择适当模式（如“完全”或“灵活”），避免浏览器显示证书错误。另外，确保未启用 DNSSEC，否则 Cloudflare 验证会失败。 这里展开一下：
- 备份记录：尤其注意那些不常用的记录类型，比如 SRV、TXT（SPF、DKIM、DMARC）、CAA。如果只有常规 A/AAAA/CNAME，手动记下来也行。
- TTL 降为 300 秒：通常旧 DNS 的 TTL 默认是 3600 秒（1小时）或更高。提前半天到一天降低，可以让切换后新记录更快全球生效。注意，这个动作是在旧 DNS 服务商后台改，不是 Cloudflare 里改。
- DNSSEC 关闭：Cloudflare 目前不提供 DNSSEC 签名（作为免费用户），所以如果原域名启用了 DNSSEC，必须先在注册商处关闭。否则 Cloudflare 无法为域名提供解析，访客会收到 SERVFAIL 错误。

在 Cloudflare 添加域名并核对记录

登录 Cloudflare 后，输入域名添加。系统会自动扫描当前 DNS 记录并导入。这个步骤很关键，因为扫描不一定完全准确。登录 Cloudflare 后添加域名，系统会自动扫描并导入现有 DNS 记录。务必逐条核对，尤其关注 MX（邮件）、TXT（验证/SPF）和 CNAME（别名）记录。若扫描不全，可导出原 DNS 服务商的记录文件（如 BIND 格式），再手动添加至 Cloudflare。注意将 A 记录指向正确的服务器 IP，避免网站中断。 实际操作中，我遇到过几次扫描遗漏的情况，特别是存在多值 TXT 记录时（例如多个 SPF 条目），Cloudflare 只导入了第一条。所以建议在 Cloudflare 的 DNS 页面里，把每条记录和原后台逐一比对。如果原服务商支持导出 BIND 格式区域文件，可以直接用 Cloudflare 的“批量导入”功能，但导入后仍需手动检查。

另外，专门提一下代理云朵（Proxy）开关。Cloudflare 默认会给新添加的记录开启灰色云朵（仅 DNS），如果需要 CDN 和隐藏源 IP，则点击云朵变为橙色。但刚开始切换时，建议先保持灰色（仅 DNS），等 NS 记录完全生效且网站访问正常后，再逐个开启代理。这样可以降低因代理配置错误导致的 521/522 等源站连接错误。

更换 NS 记录并等待传播

确认 Cloudflare 里的记录无误后，去域名注册商的控制面板，找到 DNS 管理或域名服务器设置，将当前的 NS 记录替换为 Cloudflare 提供的两个名称服务器（例如 alina.ns.cloudflare.com 和 carlos.ns.cloudflare.com）。不同注册商的生效时间不同，快的几分钟，慢的 48 小时。素材3提到：修改后，全球 DNS 传播通常需几分钟至 48 小时。在此期间，建议暂停 Cloudflare 的代理（橙色云朵图标）以降低潜在访问问题。通过 dig 或 nslookup 命令可实时检查 NS 记录是否生效。 我一般习惯用 dig +short NS example.com @1.1.1.1 或 nslookup -type=NS example.com 8.8.8.8 来轮询检查，如果返回了 Cloudflare 的 NS 地址，说明该递归服务器已经完成更新。但不同地区可能不同，可以在 whatsmydns.net 这类工具上检查全球状态。

切换后的验证与常见问题

当确认绝大多数 DNS 服务器已经指向 Cloudflare 后，可以做几个检查：
- 访问网站能不能正常打开，浏览器有没有证书错误。如果使用 Cloudflare 的 SSL（推荐“完全”模式），需要确保源站也有有效证书（自签名也可，只要开启“完全（严格）”需要 CA 签发证书）。
- 发送测试邮件到自己的域名邮箱，确认 MX 记录工作正常。如果原邮件服务器 IP 未变，一般没问题；但如果有 SPF/DKIM 记录，要确认是否被 Cloudflare 自动导入。
- 检查第三方服务（如 Github Pages 的自定义域名、CDN 的 CNAME 回源）是否仍能解析。如果有 ANAME 或 CNAME flattening 等特殊记录，需要确认 Cloudflare 是否支持（支持通过 CNAME 实现类似效果）。

如果遇到访问失败，最快回滚方式就是把注册商的 NS 地址改回原来的值，同时所有 Cloudflare 配置保留但暂时停止使用。回滚前建议先 TTL 调高，避免卡住。不过大多数情况只要记录配置正确，切换本身风险很低。

小问题： 迁移后邮箱还能正常收信吗？
会的，只要 MX 记录保持一致。但要注意有些注册商在更换 NS 后会删除原来的自动邮件转发规则，所以如果依赖注册商的邮件转发，建议先迁移到第三方邮箱服务（如 mailgun、Zoho）后再切换。