Caddy HTTPS 教程：证书、80/443 与故障排查 | AIOOS

Caddy 自动做了什么

当公开域名出现在有效的 Caddy 配置里时，Caddy 通常会启用自动 HTTPS：申请受信任证书、在到期前续期，并把 HTTP 跳转到 HTTPS。它是自动化，不是魔法。域名必须解析到这台服务器，验证流量能到达 Caddy，服务正在运行，证书机构也必须能验证你控制这个域名。

Caddy 自动 HTTPS 官方文档列出的常见条件包括：A 或 AAAA 指向正确服务器，公网可以访问 80 和 443，域名确实写在配置里，并且 Caddy 数据目录可持续写入。升级时要保留 /var/lib/caddy，不要让证书状态随着每次部署一起消失。

第一步：只检查 DNS

下面命令从自己的电脑执行，不要只在服务器本机查。域名替换为真实值。

bash

dig +short A example.com
dig +short AAAA example.com
dig +short A www.example.com

A 必须是服务器公网 IPv4。只要 AAAA 有结果，就要单独测试那条 IPv6；服务器没有完整配置 IPv6 时，应删除误加的 AAAA。如果你自己配置过 CAA，再用 dig CAA example.com 检查，限制过严可能阻止当前证书机构签发。

第二步：检查公网到进程的路线

云厂商安全组和系统 UFW 是两层开关，两边都要允许必要流量。在服务器确认到底哪个进程占用了端口：

bash

sudo ufw status verbose
sudo ss -ltnp | grep -E ':(80|443)\b'
systemctl status caddy --no-pager

80 和 443 应由 Caddy 监听，或者通过明确的网络结构转给它。如果看到 Nginx、Apache 或遗留进程占用端口，先决定到底保留哪一个 Web 服务器，不要让两个服务互相抢端口再反复重启。从另一条网络执行 curl -I http://example.com；一直超时通常先查路由和防火墙，而不是先改证书配置。

第三步：校验配置，读第一条错误

bash

sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy
journalctl -u caddy --since '15 minutes ago' --no-pager

重点看第一条与证书或监听有关的错误，不要只看最后一句“稍后重试”。DNS 查不到、连接超时、连接拒绝和签发频率限制是四种不同问题。修复明确原因后重载一次，毫无方向地连续改动只会让日志更难读。

第四步：检查公网响应和证书名称

bash

curl -4 -I https://example.com
curl -I https://www.example.com
openssl s_client -connect example.com:443 -servername example.com </dev/null

证书名称必须覆盖正在访问的主机，生效和到期时间应合理，www 跳转要指向你选定的正式域名。只有一台设备出现浏览器警告时，可能是本地缓存，但仍要用 curl 和第二条网络交叉确认，不能直接忽略。

常见故障对照

• IPv4 正确、IPv6 错误：一部分人能打开，另一部分人一直失败。修好或删除 AAAA。

• 80 或 443 超时：同时检查云安全组与 UFW，缺一层都不通。

• Address already in use：先用 ss 找占用者，不要凭服务名称乱停进程。

• Caddyfile 没有真实域名：只写 IP 或 localhost，不会得到预期的公网域名证书。

• 系统时间错误：证书时间和日志都会误导，先检查 timedatectl status。

• 持续签发失败：停止反复重试，读清错误，不要删除 Caddy 数据目录“重新来过”。

我的踩坑体会

我以前看见浏览器红色警告，就把所有问题统称为“证书坏了”。后来发现多数失败都在证书之前：旧 DNS、误配 AAAA、云防火墙没开。现在固定按“域名、网络、监听、配置、证书”的顺序检查，哪一层先失败，就只处理哪一层。

完成标准

HTTP 自动跳到 HTTPS，正式域名返回 200，已经发布的 IPv4 和 IPv6 路线都能访问，Caddy 日志没有重复签发错误，才算 HTTPS 完成。接下来补上监控、备份与恢复，网站才真正进入可运营状态。