自动化续期场景下，HTTP-01 和 DNS-01 到底怎么选
HTTP-01 和 DNS-01 都能拿到 Let's Encrypt 证书，但在自动化续期、通配符证书和负载均衡后端环境里，两者的坑完全不同。本文按实际部署场景拆解取舍，帮你选出能在凌晨两点不出事的那个。
本文目录
凌晨三点的告警很常见：证书过期了，可续期脚本明明"一直在跑"。排查下来，十有八九是验证方式选错了——当时图省事用了 HTTP-01，后来架构变了，80 端口的路由被某次改动悄悄截断，续期就一直静默失败。
HTTP-01 和 DNS-01 在 CA 眼里是平等的，拿到的证书一模一样。区别只在"你怎么证明域名归你"，而这个区别决定了自动化场景下的可靠性。
HTTP-01：简单，但依赖 HTTP 路径完好
CA 会访问 http://域名/.well-known/acme-challenge/xxx，你的客户端把对应内容放在那里即可。配置直观，调试也容易——curl 一把就知道通不通。
但它有几个硬性前提：
- 80 端口必须能从公网直达，且请求能落到跑 ACME 客户端的那台机器。
- 通配符证书（
*.example.com）不支持 HTTP-01，这是协议层面的限制，不是 CA 的政策问题。 - 多机负载均衡环境下，CA 的请求可能落到任意一台后端。要么所有机器都能应答同一个 challenge（共享存储或代理转发），要么把
/.well-known/acme-challenge/统一反代到一台固定机器。很多"时好时坏"的续期失败就是这么来的：请求偶尔落到配置过的那台，偶尔不落。
如果你的架构就是单台 Nginx 加一个域名，HTTP-01 完全够用，没必要折腾 DNS。
DNS-01：麻烦一次，省心很久
DNS-01 要求你在域名下创建一条 _acme-challenge.域名 的 TXT 记录。CA 查 DNS 来验证，不碰你的 Web 服务。
代价是要接 DNS 服务商的 API，凭据要妥善保管。换来的是：
- 唯一能签通配符证书的方式。
- 不依赖 80 端口、不依赖 Web 架构，后端怎么扩容、怎么换都不影响续期。
- 服务在内网、没有公网入口时也能签——只要 DNS 在公网解析就行。
一个小坑：TXT 记录生效有传播延迟，客户端通常要等几秒到几十秒再去触发 CA 校验。还有，别为了图方便把主域 DNS 的 API 凭据（能改所有记录的那种）直接塞进每台服务器。更稳妥的做法是单独建一个 _acme-challenge.example.com 的 CNAME，指向一个专门用于验证的子域或独立 DNS 账户，凭据权限就小得多。
按场景对号
- 单机、少数几个具体域名、80 端口稳定可达：HTTP-01，简单就是优势。
- 需要通配符：DNS-01，没得选。
- 负载均衡多后端：DNS-01。HTTP-01 也能做，但要额外维护 challenge 的统一路由，长期看是债。
- 内网服务、CDN 回源、80 端口被占用或封闭：DNS-01。
- DNS 服务商没有 API、也不支持 CNAME 委托：这种情况下 HTTP-01 反而更现实，或者考虑换 DNS 托管。
一句话判断标准：验证路径上任何一个环节变了，续期会不会悄悄挂掉？会的那条路，迟早会在凌晨找你。
在 CertbotX 中实践
CertbotX 的 DNS-01 流程支持 CNAME 委托：把 _acme-challenge 记录指向专门的验证域，主域 DNS 凭据就不用下放到服务器。签发后由 ACME 自动管理到期前重新签发，证书可直接部署到 Agent、EdgeOne 或其他 CDN，每次部署有记录可查，出了问题能回溯是哪次续期、发到了哪里。对多后端或内网服务这类 HTTP-01 容易翻车的场景，这条链路基本不需要人工介入。
核验参考
- Let's Encrypt 官方文档：验证方式说明，确认 HTTP-01 不支持通配符等限制。
- RFC 8555（ACME 协议），了解 challenge 机制本身。
- Nginx HTTPS 配置文档，配置证书和 challenge 反代时可对照。