网站换服务器时，修改 A 记录只占几秒钟。真正耗时间的是后面的判断：记录改到了哪个账号？还有没有旧 AAAA？橙云是不是仍开着？证书正常，为什么浏览器还是进不去？Cloudflare 新 CLI cf 的价值，在于把这些变更之前的查询和记录做得更方便。
这里不以“全自动迁站”为目标，而是把一项 DNS 变更拆成可检查的步骤。先查清楚当前状态，再预览请求，最后确认访问结果。命令依据 2026 年 9 月 30 日的官方 Beta 文档；示例不包含任何实际网站的源站地址。
DNS 管理不需要创建 Workers 项目
cf 提供公共 API 命令，可以在普通目录运行，不要求先生成 cloudflare.config.ts。如果只管理域名，不必先 cf init，也不必把 VPS 应用迁移到 Workers。
安装要求 Node.js 22.18 或更新版本：
npm install --global cf
cf --version
cf auth login
cf auth whoami
新工具不会继承 Wrangler 的登录凭据，需要单独认证。无交互脚本则使用 API Token，并限定它能管理的域名及权限。能列出区域与能修改区域内 DNS 是不同操作，不要只看登录是否成功。cf 安装说明
先把域名和区域 ID 对上
cf zones list --name example.com
cf dns records list --zone example.com
zone 可以理解为 Cloudflare 管理的域名区域。记录 ID、zone ID 和 account ID 分别指向不同对象，后面写脚本时需要保留完整对应关系。多个账号时，显式设置正确的 CLOUDFLARE_ACCOUNT_ID，减少交互选择或旧缓存造成的歧义。
不要仅凭“网站现在能打开”判断记录状态。Cloudflare 控制台里的记录、公网递归解析器里的缓存和浏览器的连接结果，是三个不同观察点。变更前留一份记录输出，至少能知道准备修改的对象原来是什么。
cf dns records list --zone example.com --type A
cf dns records list --zone example.com --type AAAA
域名同时有 A 和 AAAA 时，支持 IPv6 的客户端可能走另一条路径。如果只改 IPv4，而旧 IPv6 地址仍指向以前的服务，网站就会表现为有些网络正常、有些网络异常。不要因此直接删除所有 AAAA，先确认服务器是否仍提供正确的 IPv6 服务。
导出时，记住“列表”可能只有第一页
官方说明 cf dns records list 每次返回一页。先看帮助，确认分页参数，再按页面收集：
cf dns records list --help
cf dns records list --zone example.com --page 1 --per-page 100 > dns-page-1.json
记录超过一页时继续取后续页。把结果合并前，检查退出状态和 JSON 是否能解析。不要因为文件非空就认定备份完成，错误、空列表和第一页列表都可能让脚本产生错误判断。
如果安装了 jq，可以整理为便于审阅的表格：
jq -r '.[] | [.id, .type, .name, .content, .proxied] | @tsv' dns-page-1.json
这份文件适合做变更前快照，但不是“整个域名设置”的备份。缓存规则、证书设置、邮件策略和安全规则属于其他配置，不能从 DNS 列表恢复。官方 DNS 管理示例
找到命令，再看请求，不凭印象写参数
cf cli search "create a DNS record"
cf schema dns records create
cf dns records create --help
搜索结果里会同时出现 create、edit、update 等入口。当前版本命令摘要将 edit 描述为更新、update 描述为覆盖，这也提醒我们：英文名字相近，不等于修改语义相同。更新已有记录前应检查对应 API 说明，确认哪些字段必须提供，不能把新增命令拿来反复运行。
某些操作只接受完整 JSON 请求体，schema 展示的字段列表也可能不完整。帮助用于检查命令用法，API 文档用于确认请求体结构，两者配合才够用。创建记录 API
创建 DNS 记录的请求预览，使用示例区域 ID 和文档地址。
用测试子域名走一遍流程
先预览一条记录：
cf dns records create \
--zone 00000000000000000000000000000000 \
--body '{"type":"A","name":"test","content":"192.0.2.1","proxied":false}' \
--dry-run
预览结果应包含 POST 方法、目标 zone 的路径和 JSON 内容。dry run 不会按域名名称查询 zone，所以这里使用 ID。示例 ID 和地址都不能拿来正式创建记录。
在真实操作中，换成自己的区域 ID、测试子域名及受控服务器地址。先确认这个名称没有现存记录或业务，再决定是否执行。运行不带 dry run 的命令会真的改远程资源，不是另一种形式的演示。
本文没有替读者实际创建测试记录。建议第一次练习不要选根域名、邮件记录或线上 API 地址；选一个没有业务依赖的名称，出了问题更容易判断影响范围。
橙云与灰云，是访问路径的选择
proxied 是 DNS 请求体里的一个字段。对支持代理的记录，true 表示流量经 Cloudflare 代理，false 表示直接解析到源站。它不是一个单纯的“提速按钮”。
走代理时，用户到 Cloudflare、Cloudflare 到源站分别是一段链路；直接解析则由用户连接源站。哪种更快取决于用户网络、源站线路、内容大小和缓存情况，不能凭开关颜色给所有地区下结论。代理记录的工作方式
切到直接解析前，要检查源站允许的来源地址。有的反向代理只接受 CDN 出口 IP，去掉代理后仍保留这条限制，访客就会遇到 403 或类似“Direct origin access denied”的错误。这种情况下 DNS 可以完全正确，问题仍在服务器的访问规则。
源站证书也要适合浏览器直接访问。DNS 修改不会替你申请公开可信证书，更不会替 Caddy、Nginx 或应用修改域名配置。
执行后，用三层证据验收
第一层是资源回读：通过 CLI 再列出对应名称，核对 ID、内容和代理状态。第二层是解析结果：查询权威 DNS，并对比常用递归解析器。第三层才是网页访问：保留原域名与 TLS 校验，检查首页、文章及图片。
dig NS example.com
dig A test.example.com
dig AAAA test.example.com
curl -I https://test.example.com/
需要查权威结果时，根据 NS 查询得到的真实服务器运行 dig @<权威服务器> ...。代理开启时，公网解析显示代理地址而非源站地址是正常现象；直接解析时才应看到配置的目标地址。
记录值已经回读成功，但一部分递归解析器仍返回旧值，可能是缓存尚未过期。把测试时间、解析器和结果记下来，避免反复来回修改记录，让迁移状态更加混乱。
删除记录的脚本，不能只看退出码
官方文档特别提到：无交互环境中的删除命令，未带 --force 时会中止、输出 Aborted.，退出状态却可能是 0。脚本看到成功退出，不代表记录已经删除。
因此，删除之后必须查询资源是否仍存在。--force 在部分命令中还有 API 层面的含义，不宜作为所有命令的默认参数。整理旧记录时，按记录 ID、类型、名称逐项确认，别把同名的 MX 或 TXT 一起处理掉。无交互行为说明
CLI 带来的便利是把操作过程留下来；一次迁移是否完成，仍要由记录回读和真实访问共同确认。