HTTP-01 和 DNS-01 怎么选：通配符、多机部署和被封的 80 端口
同样是 ACME 验证域名控制权，HTTP-01 和 DNS-01 在通配符支持、多机部署、内网服务和防火墙限制上差别很大。本文按实际场景拆解两者的取舍和常见坑。
本文目录
证书签发失败，十有八九不是 CA 的问题，而是验证这一步没走通。ACME 协议里最常用的两种验证方式——HTTP-01 和 DNS-01——看起来只是"证明你控制这个域名"的两种姿势，但落到实际环境，它们几乎是两套运维方案。选错了，轻则每次续签都得手动折腾，重则某些场景根本签不下来。
HTTP-01：简单，但挑环境
HTTP-01 的流程很直白：CA 要求你在 http://域名/.well-known/acme-challenge/ 下放一个临时 token，它通过 80 端口访问，拿到就算通过。在单机、有公网 80 端口、域名直接指向这台机器的场景里，这是最低成本的方案——一个 Certbot 命令，几分钟搞定。
但它的限制全是硬性的：
- 签不了通配符证书。
* .example.com只能走 DNS-01，这是 Let's Encrypt 的明确策略，没有商量余地。想要通配符，HTTP-01 这条路从第一天就是断的。 - 必须能从公网访问 80 端口。公司防火墙只放行 443、服务器在内网、域名前面挂着 CDN 而且回源策略复杂——这些都会让 CA 的验证请求要么到不了，要么到错机器。
- 多机部署很尴尬。证书要签给
example.com，但流量通过负载均衡打到五台机器上，CA 的请求随机落到哪一台，哪一台就得恰好能应答。常见的解法是各机器把 challenge 请求转发到固定的验证节点，或者用共享存储同步 token——能解，但已经不算"简单方案"了。
还有一个容易忽略的点：CA 的验证是从多个网络位置发起的。如果你的防火墙有地域性放行策略，验证可能时灵时不灵，排查起来比"彻底不通"更折磨人。
DNS-01：多一步，但几乎没有场景限制
DNS-01 要求你在 _acme-challenge.域名 下放一条 TXT 记录，CA 直接查 DNS。它不碰你的 Web 服务，所以 80 端口封不封、机器在内网还是外网、前面有没有 CDN，统统无所谓。通配符证书也只认这条路。
代价是两件事：
- DNS 变更必须能自动化，否则每次续签都是手动改记录。手动改一次不可怕，可怕的是 90 天到期前你忘了，而且往往忘得最准的那次恰好是节假日。所以 DNS-01 的实用前提是你的 DNS 提供商有 API，或者你可以用 CNAME 委托。
- DNS 传播有延迟。TXT 记录写进去到 CA 能查到之间要等，客户端一般会做轮询确认，但遇到 TTL 设置异常或者主从同步慢的 DNS 服务，签发时间会被拉长。
CNAME 委托是个值得单独说的技巧：把 _acme-challenge.域名 CNAME 到一个专门用于验证的子域（可以放在另一个支持 API 的 DNS 区里），验证记录的读写只影响那个子域，不用碰主域的 DNS 权限。这对"主域 DNS 权限在别的部门/供应商手里"的团队特别现实——你拿到的是一个小范围的钥匙，而不是整栋楼的门禁。
实际怎么选
经验法则：
- 单域名、单机、80 端口开放、不打算要通配符 → HTTP-01，配置最少，故障点最少。
- 要通配符、内网服务、端口受限、CDN 后面、多机/容器环境 → DNS-01，别犹豫。
- 两种情况混着的团队（很常见：官网单机，内部平台一堆子域名想要通配符）→ 可以混用，但建议尽量收敛到一种，续签巡检时少一套心智负担。
一个小坑提醒：通配符证书 *.example.com 不覆盖 example.com 本身，SAN 里两个都得写上。这个和验证方式无关，但选了 DNS-01 去签通配符的人经常会漏掉裸域，签完才发现。
在 CertbotX 中实践
CertbotX 支持 DNS-01 的 CNAME 委托模式：把验证子域指向 CertbotX 管理的区域后，ACME 自动签发和到期前的自动重新签发就完全不依赖人工改 DNS 了。签发后的证书可以自动部署到 Agent、EdgeOne 或 CDN，并且每次部署都有记录可查——对需要回答"这台机器上的证书是什么时候、被谁更新的"这类审计问题的团队，这条链路从签发到落地是闭环的。对前面说的"DNS 权限不在自己手里"的场景，CNAME 委托恰好把权限边界切得很干净。
参考
- Let's Encrypt：Challenge Types 官方说明——两种验证方式的机制和限制，包括通配符必须走 DNS-01 的依据
- RFC 8555 (ACME 协议)——HTTP-01 与 DNS-01 挑战的协议定义