一、HTTP-01 的网络可达性约束
1. 工作原理的拓扑依赖
HTTP-01 挑战要求 CA 的验证服务器能够通过公网发起 HTTP 请求，访问被验证域名的 80 端口，并读取 /.well-known/acme-challenge/ 路径下的验证令牌。这一机制对网络拓扑提出了明确的约束：
服务器必须具备公网可达的 IP 地址。对于部署在私有网络中的服务器——如企业内网的开发环境、VPN 内的测试节点——HTTP-01 无法直接使用。
80 端口必须对公网开放。部分运营商默认封锁家庭宽带和中小商业用户的 80 端口入站流量，IaaS 环境的安全组也可能仅开放了 443。这种情况下 HTTP-01 会因连接超时而失败。
DNS 解析结果必须指向该服务器。对于使用 CDN 或反向代理的站点，DNS 解析可能指向边缘节点而非源站。如果验证文件仅部署在源站，CDN 边缘节点返回 404，验证同样失败。
2. 多服务器集群的分发难题
当同一个域名由多台服务器共同服务时（如 DNS 轮询或流量分发器后的后端集群），HTTP-01 面临验证文件同步问题：
CA 的验证请求可能落到集群中的任意一台服务器上。如果验证文件仅部署在 A 服务器，而验证请求路由至 B 服务器，B 返回 404 即验证失败。解决这一问题的常见思路包括：
- 共享存储：将
/.well-known/acme-challenge/目录接入到所有服务器共享的网络文件系统（NFS、分布式文件系统）上。但引入共享存储本身增加了架构复杂度和故障点——共享存储一旦不可用，所有服务器的证书续期都将中断。
- 流量分发器规则：在流量分发器上配置路径级路由，将
/.well-known/acme-challenge/的请求固定转发至一台专用的验证服务器。该方法无需共享存储，但要求流量分发器支持路径级路由规则，且专用验证服务器成为证书续期的单点。
- DNS 切换方案：在证书续期期间临时将 DNS 解析指向验证服务器，续期完成后恢复。该方法通用性最高，但 DNS 变更的传播延迟（数分钟至数十分钟）使得证书续期的整体耗时较长。
3. HTTP-01 的通配符盲区
HTTP-01 最大的能力上限是不支持通配符证书。通配符证书覆盖所有一级子域名，需要一个能证明"我控制整个域名的 DNS"而非"我控制某台服务器的某个路径"的验证机制。HTTP-01 的 Web 文件验证逻辑本质上绑定的是单一服务器上的单一域名，无法延伸到通配符范围。
二、DNS-01 的通用性优势
1. 解耦网络可达性
DNS-01 挑战的验证不经过 Web 服务器——CA 通过全球分布的 DNS 解析节点查询域名的 TXT 记录 _acme-challenge.{domain}，匹配哈希值后即完成验证。这一机制将验证通道从"HTTP 请求"切换为"DNS 查询"，彻底解耦了对服务器网络可达性的依赖。
对于以下场景，DNS-01 几乎是唯一的可行方案：
- 服务器位于内部网络，无公网 IP 地址；
- 80 端口不可用（无论什么原因）；
- 使用 CDN 且无法配置源站穿透规则；
- 需要通配符证书。
2. DNS API 集成的深度要求
DNS-01 的门槛不在网络拓扑，而在 DNS 托管服务的 API 接入。ACME 客户端需要具备通过 API 修改 DNS 记录的能力，这要求 DNS 服务商提供开放接口且客户端持有相应的写入权限凭证。
权限管理是此环节的核心安全关切。拥有 DNS 写入权限意味着可以修改任何记录类型——不仅是 TXT 验证记录，还包括 A 记录（劫持流量）、MX 记录（拦截邮件）。建议在 DNS 服务商侧创建受限子账户，仅授予 _acme-challenge 前缀的 TXT 记录写入权限，从根上控制凭证泄露的爆破半径。
3. 集中化管理的架构收益
在多服务器场景中，DNS-01 的集中化优势尤为突出。ACME 客户端只需在一台机器上运行，通过 DNS API 完成验证，证书签发后分发到所有服务器。不再需要协调多台服务器上的文件同步、路由规则或 DNS 切换——管理复杂度从 O(n) 降为 O(1)。
对于容器编排环境，这一集中化特性与证书管理工具的 Sidecar 模式天然契合——一个集中的证书控制器负责通过 DNS-01 完成签发，然后将证书注入到各容器的数据卷中。整个流程无需各容器具备公网 IP 或开放 80 端口。
三、网络拓扑驱动的选型决策
1. 单服务器 + 公网可达 + 80 端口开放
这是 HTTP-01 的理想场景。配置最简——ACME 客户端直接在本地 Web 服务器的文档根目录下写入验证文件，验证完成后自动清理。无需 DNS API 权限，无需额外组件。
2. 公网可达但仅有 443 端口
HTTP-01 请求走 80 端口，此场景下无法直接使用。TLS-ALPN-01 是备选方案——在 TLS 握手阶段通过 ALPN 扩展完成验证，不需要 80 端口。但 TLS-ALPN-01 的支持范围不如 HTTP-01 和 DNS-01 广泛，部分 CA 不支持，且与部分流量分发器和 WAF 存在兼容性问题。如果 TLS-ALPN-01 不可行，DNS-01 是唯一选项。
3. 无公网可达或使用 CDN
DNS-01 是此场景的唯一可行方案。无论服务器的网络位置如何，只要能够通过 DNS API 修改记录，验证即可完成。
4. 需要通配符证书
无论网络拓扑如何，只要需求中包含通配符证书，DNS-01 就是必选项。HTTP-01 和 TLS-ALPN-01 均不支持通配符。
选择验证方式的核心不是比较 HTTP-01 和 DNS-01 的绝对优劣，而是评估当前网络拓扑是否满足 HTTP-01 的约束条件。如果满足，HTTP-01 的简洁性值得优先考虑；一旦约束条件不满足，DNS-01 的通用性使其成为流量分发器集群、CDN 架构和通配符场景的可靠方案。在多数生产环境中，两种方式各司其职——公网服务用 HTTP-01 简化部署，内网与通配符场景走 DNS-01——是经过验证的高效组合。
