同一台服务器既要续期又要躲端口封禁：HTTP-01 和 DNS-01 到底选哪个

凌晨三点收到续期失败告警，登上机器一看，证书还剩五天，Certbot 报错却很简单：Timeout during connect。原因也不复杂——站点前面挂了 CDN，80 端口的回源请求被边缘节点自己消化了，Let's Encrypt 的验证服务器根本摸不到源站上的挑战文件。这就是 HTTP-01 最经典的翻车现场。

HTTP-01 的工作方式是：ACME 服务器向你的域名发一个 HTTP 请求，路径是 /.well-known/acme-challenge/，你的客户端提前把文件放在那儿。它简单、不需要碰 DNS、任何 Web 服务器都能配合。但前提条件很硬：

• 80 端口必须能从公网直达你的验证客户端
• 域名解析到的所有节点都得能应答这个挑战
• 不能签发泛域名证书（这是协议限制，不是实现问题）

三个前提里有一个不满足，HTTP-01 就开始变得像抽奖。多节点负载均衡后面只跑了一个 ACME 客户端？Let's Encrypt 的验证可能打到另一台没放挑战文件的机器上。有些团队给所有节点同步 webroot，或者把 .well-known 反代到单台机器，能用，但每加一个节点就多一处要维护的默契。

DNS-01 走的是另一条路：往 _acme-challenge.example.com 写一条 TXT 记录，ACME 服务器查 DNS 就算数。它不关心你的 80 端口开没开、前面有没有 CDN、服务跑在内网还是哪朵云里。代价是要能自动改 DNS——也就是 API 凭据，而且这份凭据的权限往往比你想象的大。一个能改 DNS 的 token 泄露，和丢一个只读 webroot 的权限，完全不是一个量级的事故。

按场景给一个直接的判断：

单台机器、80 端口干净、不碰泛域名——用 HTTP-01。少一份凭据，少一个故障面，挑战文件扔在 webroot 里就完事。

要泛域名证书——只能 DNS-01，没得选。.example.com 一张证书盖住所有子域，比给二十个子域各签一张好管得多。

CDN 或反代在前面——看你能不能稳定控制 80 端口的回源路径。控制不了就 DNS-01，别和边缘节点的缓存策略搏斗。

内网服务、域名不对外——DNS-01 几乎是唯一选项。域名可以在公网 DNS 里解析，TXT 记录照样写，ACME 服务器只查 DNS，不访问你的服务。很多人以为内网证书只能自签，其实是被 HTTP-01 的思维定式困住了。

多节点共享一张证书——DNS-01 更省心。证书签发一次，再分发到各节点；HTTP-01 则需要保证"验证时所有节点都能应答"，这件事在扩容缩容时最容易悄悄断掉。

DNS-01 还有两个实操小坑值得说。一是 TXT 传播延迟：写完记录马上让 ACME 服务器查，可能查到旧缓存，客户端通常需要等待几十秒到几分钟再提交验证。二是凭据权限：DNS 服务商的 API key 经常是账户级全权，只为了能写一条 TXT 就把整个域名的生杀大权交给一台 Web 服务器，怎么想都不舒服。

第二个坑有个标准解法：CNAME 委托。把 _acme-challenge.example.com CNAME 到一个专门的子域（比如 _acme-challenge.example.com.acme-dns.example.net），只对那个子域授权写 TXT 的凭据。主域的 DNS 权限留在自己手里，泄露面一下子缩小了。

在 CertbotX 中实践：这正是我们处理 DNS-01 的方式——支持 CNAME 委托，把验证用的 TXT 记录隔离到独立子域，主域凭据不必下发。证书通过 ACME 自动签发、到期前自动重新签发，签完可以直接推送到 Agent、EdgeOne 或 CDN 上，每一次部署都有记录可查，出了"证书到底推到哪台了"这种问题时不用靠回忆。多节点场景下，集中签发加分发的模式也绕开了 HTTP-01 那种"每台机器都得应答"的耦合。

回到开头那个凌晨三点的告警：把验证方式从 HTTP-01 换成 DNS-01 加 CNAME 委托之后，CDN 在前面怎么改缓存策略都不影响续期。这不是说 HTTP-01 不好——它依然是条件满足时最省事的选择——而是说验证方式要跟着网络拓扑走，而不是跟着习惯走。

延伸阅读：

• Let's Encrypt：Challenge Types —— 官方对 HTTP-01、DNS-01 等验证方式及限制（如泛域名必须 DNS-01）的说明
• RFC 8555：ACME 协议 —— 第 8 节定义了各类挑战的协议细节，想搞清验证流程可以读这里