基于 Porkbun、Cloudflare 和 Wrangler 的代理式域名运维

我将 Porkbun 和 Cloudflare 接入了一个代理程序，它负责处理从“我有个想法”到“网站真正上线”之间的那些无聊环节。应要求，我来写写如何利用代理程序自动化域名运维，并附上实际用例和代码示例。

注意：本文由一台本地大语言模型生成，该模型全面探索了我的工作流程。目标是解释系统如何工作，而不暴露具体路径、主机名、域名、凭据或内部结构。文章经过审核，确认准确且能代表我的实际工作流程。

代理程序能做什么？

• 检查域名是否可注册
• 购买或注册域名
• 设置注册商 DNS 服务器
• 将 DNS 权威移至 Cloudflare
• 创建和更新 DNS 记录
• 通过 Cloudflare Pages 部署静态站点
• 为服务/应用设置反向代理
• 关联 apex 和 www 自定义域名
• 配置边缘重定向
• 验证实时互联网是否看到预期结果

更有用的部分是，我如何系统地进行这一切的整体结构：操作手册、期望状态文件、备份、确认关卡和验证命令。代理程序不能随意乱搞。

布局概览

通用版本如下：

• registrarctl：封装 Porkbun 注册商和 DNS 操作。
• cf-zone-migrate：将 Porkbun 托管的 DNS 迁移至 Cloudflare DNS 权威。
• cf-pagesctl：通过 Wrangler 加 Cloudflare API 部署和验证 Cloudflare Pages 站点。
• cf-redirectctl：管理 Cloudflare 批量重定向的期望状态。
• cf-proxy-audit：审计并修复 Web 记录的 Cloudflare 代理状态。
• route-bootstrap：为非 Cloudflare Pages 的服务处理面向互联网的反向代理路由。

代理程序先读取操作手册，然后是期望状态文件，最后是匹配的脚本。这个顺序很重要。

我不希望它“记住”上次 DNS 是怎么工作的。我希望它每次都读取当前的操作手册，并执行相同的受保护步骤。

凭据不放在工作流文件中

工作流文件中包含示例，而非机密信息。

代理程序可以调用工作流，但我将凭据保留在它读取和编辑的文件之外。

脚本 1: registrarctl

我将 registrarctl 称为 Porkbun 控制界面。它是与 Porkbun API 通信并处理实际记录更改的单一脚本。

该脚本涵盖：

• API 烟雾测试
• 价格检查
• 域名可用性检查
• 投资组合清单
• 到期和自动续费审计
• 域名注册
• 续费和转移操作
• 注册商 DNS 服务器的读取和更新
• Glue 记录
• URL 转发
• DNSSEC 记录
• Porkbun 托管 DNS 的读写

只读命令适合代理程序频繁运行。

DNS 写入器会检查 CNAME 共存冲突，拒绝不明确的多记录更新（除非我要求替换全部），并使用幂等键进行写入。

脚本 2: cf-zone-migrate

cf-zone-migrate 用于常见情况：Porkbun 仍为注册商，但 Cloudflare 成为 DNS 权威。

工作流刻意保持精简：

迁移处理记录形状，而非盲目复制所有内容。

• A、AAAA、CNAME、TXT 和 MX 记录原样迁移。
• MX、TXT 以及任何无法代理的其他记录保持仅 DNS 模式。
• Web 记录遵循您设置的任何 Cloudflare 代理策略。
• 注册商托管的 NS 记录被忽略。
• 提供商标识别名记录被扁平化为真正的 A 和 AAAA 记录。
• 在写入任何内容前，先备份 Cloudflare 区域记录。
• 最终检查时验证 TLD 授权。

这使得 DNS 服务器变更不再那么可怕。代理程序不仅是在更改 DNS 服务器，它还在准备 Cloudflare 区域、备份状态、应用记录、更新注册商，并验证授权。

脚本 3: cf-pagesctl

cf-pagesctl 管理 Cloudflare Pages 站点。

期望状态文件和命令界面如下：

实践中，它处理部署循环：

• 在部署前将站点复制到干净的临时目录
• 创建或定位 Pages 项目
• 运行 wrangler pages deploy
• 将 Cloudflare DNS 指向 Pages 主机名
• 将 apex 和 www 主机名关联为 Pages 自定义域名
• 检查自定义域名激活是否完成
• 在配置时检查 Web Analytics 绑定
• 对预期的状态码和重定向运行 HTTP 探测

自定义域名步骤与 DNS 分离是有原因的。仅仅拥有指向 Pages 的 DNS 记录并不总是足够。主机名还需要关联到 Pages 项目本身。

脚本 4: cf-redirectctl

cf-redirectctl 管理 Cloudflare 批量重定向。

其命令界面很小：

该脚本处理重定向，而非 DNS。它管理 Cloudflare 账户级重定向列表和规则集，然后验证边缘行为。

期望状态决定重定向是否：

• 包含子域名
• 匹配所有路径
• 保留路径后缀
• 保留查询字符串
• 将所有流量压缩到一个确切目标

这使重定向语义明确。代理程序无需猜测某个活动域名是应该保留深层链接，还是将所有内容指向单个规范 URL。

脚本 5: cf-proxy-audit

cf-proxy-audit 是一个较小但实用的安全工具。

它审计应被代理的 Cloudflare DNS 记录，并在我要求时修复漂移。

典型用法如下：

我将其用于面向 Web 的记录，这些记录需要 Cloudflare 位于源站前方以实现重定向、边缘规则、缓存或保护。我不将其用于邮件记录、验证 TXT 记录或必须保持仅 DNS 模式的记录。

脚本 6: route-bootstrap

并非每个主机名都是静态 Pages 站点。

对于自托管服务，route-bootstrap 创建反向代理路由和匹配的 Cloudflare DNS 记录。

路由状态只是一个小的配置文件：

此路径与 Pages 分开，因为它处理不同类型的暴露：反向代理加 DNS，而非 Cloudflare Pages 加自定义域名。

代理程序工作流

代理程序不需要一个巨大的“万能工具”。它需要一个路由策略。

当我要求一个新域名时：

验证是关键

我只信任这个工作流，因为它能证明最终状态。

对于注册商和 DNS 迁移，验证检查：

• Porkbun 注册商 DNS 服务器
• Cloudflare 区域状态
• Cloudflare 记录数量
• TLD 授权
• 来自 Cloudflare DNS 服务器的权威 DNS 答案

对于 Pages，验证检查：

• Pages 源 URL
• apex 自定义域名
• www 自定义域名
• 自定义域名激活
• 预期的 HTTP 状态码
• 重定向位置
• 配置时的 Web Analytics 绑定

对于重定向，验证检查：

• Cloudflare 重定向列表状态
• 账户规则集状态
• 源主机名 DNS
• 边缘 HTTP 行为
• 路径和查询保留

真正让这一切奏效的是避免在 DNS 仍在传播时出现假阴性。验证器通过 Cloudflare 权威 DNS 服务器解析，然后使用 curl --resolve 直接命中正确的边缘节点。

这样就能测试预期的边缘路径，而不是等待每个递归解析器都能跟上。

为什么这有效

代理程序通过连接整个链条来体现价值：

我通过使每个步骤狭窄来保持工作流安全：

• 读取廉价
• 写入明确
• 付费操作需要确切确认
• DNS 服务器切换需要单独确认
• 期望状态存在于文件中
• 写入前备份 Cloudflare 状态
• 权威验证 DNS 授权
• 凭据存放在工作流文件之外
• Pages 自定义域名与 DNS 记录分开检查
• 在边缘验证重定向

当前阶段的代理式工作流需要明确：购买域名、注册、迁移 DNS 权威、部署站点、关联主机名、配置重定向，并通过相同的操作循环验证实时结果。

不再有仪表盘上的琐碎工作。

下次见。

-Ahmad