Let’s Encrypt 证书签发失败后，单纯更换申请电脑或代理 IP 通常没有帮助。证书颁发机构要验证的是你对域名的控制权：HTTP-01 会从公网访问指定挑战路径，DNS-01 会查询特定 TXT 记录，TLS-ALPN-01 则在 443 端口完成专用验证。排障要先确认使用哪种挑战，再沿 DNS、网络、CDN、反向代理和 ACME 客户端逐层检查。
第一步：保存 ACME 客户端的原始错误
不要只看面板提示“申请失败”。记录域名、挑战类型、时间、CA 返回的错误类别和详细信息。常见提示包括 DNS 解析失败、连接超时、拒绝连接、返回内容不匹配、CAA 禁止签发或频率限制。不同错误对应的方向不同。
频繁重复申请可能触发 CA 的速率限制。排查阶段优先使用客户端支持的测试或 staging 环境，确认流程后再申请正式证书。
HTTP-01 先检查 A 和 AAAA
查询域名当前的 A、AAAA 和 CNAME，确认都指向能够提供挑战文件的入口。如果有 AAAA 记录，但服务器 IPv6、防火墙或反向代理配置错误，验证可能走 IPv6 后失败；不能只因为本地 IPv4 打得开就忽略。
DNS 修改后还要考虑 TTL、递归缓存和分地区解析。可从极跃圈网址导航选择 DNS、HTTP 和 SSL 工具交叉查询，最终以权威 DNS 和 CA 返回证据为准。
80 端口与挑战路径必须公网可达
HTTP-01 通常要求外部能访问 http://域名/.well-known/acme-challenge/令牌。检查：
- 公网 80 端口是否被云安全组、系统防火墙或运营商阻断；
- 端口转发、负载均衡和反向代理是否指向运行 ACME 客户端的服务器；
- 网站是否把挑战路径重写到登录页、404 页面或另一个域名；
- 应用框架、WAF、鉴权中间件是否拦截
/.well-known/； - 多台后端是否都能访问同一挑战文件或共享验证状态。
不要关闭 TLS 校验、全站防火墙或 WAF 来“试试看”。可以为挑战路径建立精确规则，验证结束后保留自动续期所需的正常配置。
CDN 开启时要确认验证落在哪里
域名通过 CDN 代理后，CA 会先访问 CDN。CDN 必须把挑战路径正确回源，不能被缓存成旧令牌，也不能跳到另一个无关站点。若 CDN 提供自己的证书管理，先确认是由 CDN 代签边缘证书，还是源站 ACME 客户端申请回源证书，两者流程不同。
临时关闭 CDN 代理可能改变 DNS 和源站暴露面，不应作为默认方案。优先按 CDN 与 ACME 客户端官方文档配置 HTTP 或 DNS 验证。
CAA 记录为什么会阻止签发
CAA 用于声明哪些证书颁发机构可以为域名签发。检查当前域名及其父级有效 CAA 记录，确认允许所选 CA，语法没有错误。使用 CNAME、通配符或第三方托管时，还要按照 CA 文档理解查找规则。修改后等待 DNS 生效再重试。
什么时候适合 DNS-01
申请通配符证书、源站不便开放 80 端口，或需要在复杂集群中集中验证时，可以使用 DNS-01。ACME 客户端需要创建指定 TXT 记录，最好通过权限受限的 DNS API 令牌自动完成。
令牌只授予必要域名和记录权限，不要把 DNS 主账号密码写入脚本。验证失败时检查 TXT 是否发布到正确区域、是否有多份冲突记录、权威服务器是否一致，以及 DNS 提供商 API 是否已成功写入。
反向代理与容器环境的常见问题
ACME 客户端可能在一台容器生成挑战文件，而请求被负载均衡到另一台容器；Nginx 配置重新加载失败，旧规则仍在运行；Webroot 路径与容器挂载不一致；自动跳转规则覆盖了挑战 location。用一个手工测试文件验证完整公网路径，再对照客户端实际 webroot 和日志。
签发成功不代表续期一定成功
证书自动续期通常在数周后运行，届时 DNS、CDN、端口和容器可能已经变化。签发完成后执行客户端提供的续期演练或 dry-run，确认定时任务、权限、部署钩子和 Web 服务重载正常。监控证书到期时间，但不要等到最后一天才处理失败。
一份高效的排查顺序
- 读取 CA 原始错误，确认挑战类型。
- 核对 A、AAAA、CNAME 和 CAA 的权威结果。
- 从外部测试挑战 URL 或 TXT，不只在服务器本机测试。
- 检查防火墙、CDN、重定向、WAF 和反向代理日志。
- 使用 staging 修复流程，避免反复触发正式限制。
- 正式签发后执行续期演练并配置到期告警。
代理 IP 只有在它本来就是网站合法网络架构的一部分时才需要纳入排查，并不是 ACME 验证的通用解法。把域名控制证据和挑战路径修正，才是解决 Let’s Encrypt 签发失败的关键。
