先分清配置、申请与访问错误
Caddy 配置了域名以后，可以自动管理公开网站的证书，但自动化并没有取消外部验证条件。配置校验失败、证书申请失败和浏览器握手失败，是三个不同问题。先记录 Caddy 版本、启动方式、目标名称和相关日志时间，再确认错误发生在哪一步。不要一看到 HTTPS 无法访问，就删除全部证书数据或改成忽略验证。本文用演示站点解释排查顺序，不提供某次申请已经成功的虚构结果；实际恢复需要重新读取日志并从普通网络验证。
如果进程根本没有加载配置，应先运行完整配置校验，解决语法、模块或文件读取问题。如果进程已运行且日志显示正在申请证书，则继续检查域名与验证路径。浏览器已经收到证书但提示名称或信任错误时，还要确认连接到了哪台服务器，以及是否使用了内部证书。不同阶段需要保留不同证据。频繁重启容易打乱时间窗口，排查应先读取现状，再进行能解释影响的一次修改，随后对照结果。
配置中的名称必须是预期公开名称
站点地址会影响自动 HTTPS 的行为。先核对配置是否包含访问者使用的完整域名，是否不小心写成其他子域名，以及是否显式改变了协议或证书处理方式。主域名与博客子域名分别需要对应入口；某个名称证书正常，不说明另一名称也已经配置。读取完整导入后的配置，而不是只看一个片段，因为共享配置、全局选项或其他站点文件可能改变实际行为。校验通过以后，还需要确认正在运行的实例加载了这份配置。
内部名称与公开域名的证书信任方式也不同。Caddy 可以为适用的内部环境使用本地证书体系，但公开访问者不会自动信任本机的内部根证书。若部署目标是普通公开博客，就应核对公开域名的实际解析和申请日志，不要用内部信任提示解释公开证书申请。手动访问 IP 可能又是另一种场景，测试应保持与用户入口相同的名称。证书覆盖、站点匹配与 DNS 名称，需要在记录中对应起来。
核对 A、AAAA 与当前权威结果
证书机构需要验证域名控制权，因此应先确认当前权威解析指向预期入口。分别检查 A 与 AAAA，避免 IPv4 正确而 IPv6 仍指向旧服务器。若还有别名链或多个入口，逐段核对最终目标。仅在服务器上读取一个递归缓存结果，不能说明证书机构从外部看到相同信息。对于刚修改的记录，先检查权威返回，再比较递归缓存，保存时间与剩余条件。不要在权威仍然错误时不停触发新申请。
多服务器部署需要确认验证请求能够到达提供验证资源的正确实例。负载均衡、内容分发和其他代理，可能改变请求路径。它们能正常提供首页，不一定能正确处理验证请求；应核对挑战路径或 TLS 验证的转发能力。如果某个旧入口仍然参与解析，部分验证可能进入旧服务器。修复应根据完整入口清单进行，不能只在本机暂时覆盖域名以后报告外部验证已经具备条件。临时指定地址的测试只能验证该目标。
验证端口需要从外部可达
常见的 HTTP 验证使用标准 HTTP 端口，TLS-ALPN 验证使用标准 HTTPS 端口。Caddy 的默认自动化会管理适用挑战，但云安全组、主机防火墙与端口转发仍然需要允许相应路径。应用监听在内部端口，不会自动使外部验证进入它。先核对 Caddy 是否能监听入口，再从外部检查可达性。不能因为应用的健康接口在回环地址成功，就推断公开验证端口已经可用；两个请求经过的网络层不同。
还应检查端口是否被其他服务占用，以及转发是否真正到达 Caddy。共享服务器上可能存在旧代理或另一套入口，不能直接结束陌生进程来抢占。通过监听信息、服务配置和日志确认归属以后，再选择调整方式。浏览器的 HTTP 跳转行为也不能代替挑战验收：验证机构可能请求专门的资源或协商专门协议。需要按当前使用的挑战类型定位，避免将所有验证错误都处理成首页路径问题。
DNS 验证需要另一套前提
需要通配符证书或特殊网络条件时，可能选择 DNS 验证。它通过相应的 TXT 记录证明控制权，不依赖公开网站入口端口，但需要 Caddy 具备对应的 DNS 模块与受控凭据。先检查当前构建包含哪些模块，再按解析平台要求配置权限和记录传播等待。不要把 DNS 服务商的完整管理口令放进公开站点文件，也不要为了排查直接输出环境变量。权限应尽量限制到验证所需范围，具体能力仍以平台支持为准。
TXT 记录的可见性也需要向实际权威服务器核对。某个平台保存成功，并不保证所有权威节点立即提供新记录。若使用别名委派挑战区域，还要确认委派目标正确，并清理已经不需要的旧验证记录。网站 A 记录正常不能证明 DNS 验证 TXT 正常，它们是不同类型与路径。本文不提供各平台的通用凭据脚本，因为插件、权限范围和传播方式存在差异；应使用当前模块的官方说明，并保留脱敏配置与验证结果。
数据目录必须可写且持续保留
Caddy 管理证书需要持久化状态。使用 systemd、容器或交互终端启动，运行用户与数据目录可能不同，应该读取实际服务环境并确认可写权限。证书在手工启动时正常，而服务启动后重复申请，可能与两种运行方式使用了不同存储有关。不要在不了解服务身份的情况下递归修改整个系统目录的所有者，也不要把所有证书存储改成公开可读写。证书与账户状态属于需要保护的服务数据，应按最小权限管理。
重新部署时应保留正确的数据目录，并验证新进程仍使用它。临时容器若没有持久化相关目录，删除容器可能同时丢失自动化状态，后续又从头申请。保持存储持续可用，能够让续期管理沿同一状态进行。清理证书目录一般不是排查的起点；它可能丢掉仍有效的证书，并增加重新申请次数。对已经明确损坏的状态，也应先备份并根据产品说明处理，随后核对必要文件和公开访问，而不是把删除当作万能重置。
读取申请日志中的具体原因
日志应按名称和时间窗口筛选，区分 DNS 错误、验证资源不可达、权限问题、证书机构拒绝和本地配置错误。记录稳定的错误类型与必要上下文即可，避免把凭据或完整内部配置复制到公开文章。若域名有 CAA 记录，还需要确认它允许实际使用的证书机构，并核对相关名称的有效记录。不能因为证书机构名称熟悉就忽略授权条件；对于多层名称与别名，应按机构的说明理解检查规则。
反复重试还可能触及证书服务的限制。测试阶段可以按产品与机构提供的方法使用测试环境，但测试证书不会被普通浏览器当作可信公开证书。切换到正式环境以前，需要说明配置差异并完成正式验证。不要通过删除存储、换账户或循环重启来绕过问题；先解决导致失败的条件，随后让自动化按正常策略重试。诊断记录应保留最后一次具体错误与后续修改，使恢复过程可以解释，而不只是记下终于能打开。
证书取得以后检查真实访问
日志显示证书获得以后，从外部普通解析路径访问目标名称，检查证书覆盖、有效期和返回内容。可以分别验证主域名、博客与跳转入口，并确认地址族一致。使用跳过证书校验的请求只适合特定诊断，不能作为正式 HTTPS 验收。还应核对重定向没有指向错误的域名或内部端口，静态资源没有混入不安全地址。证书管理成功只解决加密身份的一部分，网站内容仍需要独立检查。
随后确认服务重启与发布更新没有更换数据目录，并观察续期相关的正常任务状态。不要修改生产时钟来模拟证书过期，它可能影响登录、排期和数据库记录。需要测试自动化边界时，可在隔离环境使用相应测试配置。生产验收只记录实际观察到的证书与访问结果，对于未来续期能力，用持久化配置与测试证据说明其条件，不能把尚未发生的续期写成已经成功。
将排查顺序固定到维护文档
一份可复用清单可以依次记录完整配置、公开名称、权威解析、验证入口、服务用户、存储权限和申请错误。每项都对应一个具体观察点，便于下次证书异常时直接缩小范围。多站点共享一个 Caddy 实例时，还应标明哪个名称受到影响，避免一个站点申请失败就重置全部站点状态。变更完成后保存校验与访问结果，并说明仍然依赖的平台条件。这样的记录比无条件反复重启更适合长期维护。
本文适用于一般公开网站的自动证书管理，企业代理、离线环境与特殊认证体系需要对应的额外配置。方法的重点是让申请失败回到实际验证条件：域名是否正确、外部能否达到验证路径、进程能否保存状态，以及机构返回了什么原因。按照这些条件处理以后，修复动作能够保持明确范围，也能保留原先有效的服务状态。没有实际访问验证之前，只能报告排查与配置已经完成，不能提前宣布公开 HTTPS 已经恢复。
实现片段
caddy version
caddy validate --config /etc/caddy/Caddyfile --adapter caddyfile
caddy list-modules
journalctl -u caddy --since '30 minutes ago' --no-pager
ss -ltnp
dig blog.example.com A
dig blog.example.com AAAA
dig blog.example.com CAA
# 外部网络进行最终验证，不添加跳过证书校验的参数
curl --verbose --max-time 20 https://blog.example.com/
评论 · 0