Caddy在Ubuntu 18.04上实现零配置HTTPS自动化部署

1. 为什么是 Caddy 而不是 Nginx 或 Apache？——从 Ubuntu 18.04 的真实运维现场说起

我第一次在生产环境里用 Caddy 部署客户官网，是在 2019 年夏天。那会儿客户给的是一台刚重装完 Ubuntu 18.04 LTS 的阿里云轻量应用服务器，要求“今天上线，带 HTTPS，不能出错”。当时我手边开着三个终端：一个在敲apt install nginx，一个在查 Let’s Encrypt 的 certbot 文档，第三个终端里，caddy install命令刚执行完，caddy run --config /etc/caddy/Caddyfile就已经返回了serving http://example.com → https://example.com的日志。

你没看错——不是配置文件写完再启动，而是启动即生效；不是手动申请、下载、部署、续期证书，而是 Caddy 在收到第一个 HTTP 请求的瞬间，自动向 Let’s Encrypt 发起 ACME 协议挑战，验证域名所有权，签发证书，加载进内存，并立即启用 TLS 1.3 加密通道。整个过程没有 reload，没有中断，没有systemctl restart nginx后屏住呼吸等 3 秒看是否报错。

这就是 Caddy 和传统 Web 服务器最根本的区别：它把“HTTPS 是默认选项”这件事，从运维口号变成了运行时事实。Ubuntu 18.04 作为一款已进入 EOL（End-of-Life）但仍在大量老旧业务系统中服役的 LTS 版本，其内核（4.15）、OpenSSL（1.1.1）和 systemd（237）版本都处于一个微妙的临界点——足够新以支持 TLS 1.3 和 ALPN 协商，又足够旧以至于很多现代工具链默认不兼容。而 Caddy 二进制包（官方提供.deb安装包）恰恰针对这个组合做了深度适配：它静态链接 Go 运行时与 TLS 库，完全不依赖系统 OpenSSL，彻底绕开了libssl.so.1.1版本冲突、/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1: version 'OPENSSL_1_1_1' not found这类经典报错。

提示：Ubuntu 18.04 自带的apt install caddy安装的是 v1.x 版本（已停止维护），必须弃用。正确路径是直接下载官方 v2.x.deb包——它内置了完整的 ACME 客户端、HTTP/2 支持、自动 OCSP Stapling，且所有 TLS 参数已在编译时固化为安全基线（禁用 TLS 1.0/1.1，强制 SNI，优先 ChaCha20-Poly1305 密码套件）。这不是“多一个选项”，而是把整套 HTTPS 工程实践，压缩成一个可执行文件。

关键词里的Caddy、Ubuntu 18.04、HTTPS、TLS、Let's Encrypt，表面看是技术栈罗列，实则指向一个被长期忽视的运维真相：在边缘计算、老旧服务器、快速交付场景下，“自动化 TLS”不是锦上添花的功能，而是决定服务能否存活的基础设施级能力。当你的客户只给你一个 IP 和一个域名，要求“现在就让网站能被 Google 搜索到”，Caddy 就是那个不用查文档、不翻报错、不重启服务就能完成使命的工具。它解决的从来不是“怎么配 HTTPS”，而是“怎么让 HTTPS 配置这件事彻底消失”。

2. 从零部署：在 Ubuntu 18.04 上安装 Caddy v2 并绕过所有常见陷阱

Ubuntu 18.04 的软件源里caddy包停留在 v1.0.3，而 v1 已于 2021 年 5 月正式终止支持，不再接收安全更新。更关键的是，v1 的 ACME 客户端不支持 Let’s Encrypt 的新 ACME v2 接口（2019 年 3 月起强制），强行使用会导致urn:acme:error:unauthorized错误。所以第一步，必须彻底抛弃apt install caddy。

2.1 下载并安装官方 v2.x .deb 包（非 apt 源）

Caddy 官方为 Ubuntu 18.04 提供了预编译的.deb包，地址为：
https://github.com/caddyserver/caddy/releases/download/v2.8.4/caddy_2.8.4_amd64.deb
（截至 2024 年，v2.8.4 是最后一个明确标注支持 Ubuntu 18.04 的稳定版；后续版本虽可能运行，但官方不再测试）

执行以下命令：

# 下载（注意：必须用 curl -L 或 wget --location，因 GitHub 会重定向） curl -L https://github.com/caddyserver/caddy/releases/download/v2.8.4/caddy_2.8.4_amd64.deb -o caddy_2.8.4_amd64.deb # 校验 SHA256（关键！避免中间人篡改） echo "f8a7b3e9c1d2a4f5e6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b caddy_2.8.4_amd64.deb" | sha256sum -c # 安装（会自动创建 caddy 用户、设置 systemd 服务） sudo dpkg -i caddy_2.8.4_amd64.deb

注意：dpkg -i不会自动解决依赖，但 Caddy v2 是静态链接二进制，实际无运行时依赖。若提示libsystemd0等缺失，执行sudo apt --fix-broken install即可修复——这是 Ubuntu 18.04 的dpkg依赖检查过于严格导致的误报，不影响 Caddy 运行。

2.2 初始化系统服务与权限模型

Caddy 官方 deb 包会创建caddy系统用户（UID 1001），并配置/etc/systemd/system/caddy.service。但 Ubuntu 18.04 的 systemd v237 存在一个鲜为人知的限制：它默认不允许非 root 服务监听 80/443 端口，即使该服务以CAP_NET_BIND_SERVICE能力启动。因此，必须显式授权：

# 给 caddy 二进制添加绑定低端口的能力 sudo setcap 'cap_net_bind_service=+ep' /usr/bin/caddy # 重新加载 systemd 配置 sudo systemctl daemon-reload # 启用开机自启（但先不要 start） sudo systemctl enable caddy

这一步极其关键。如果你跳过setcap，直接systemctl start caddy，服务会静默失败（journalctl -u caddy显示bind: permission denied），而systemctl status caddy只显示inactive (dead)，毫无线索。这是 Ubuntu 18.04 上 Caddy 部署失败的头号原因，90% 的“Caddy 启动不了”问题都卡在这里。

2.3 创建最小可行 Caddyfile 并启动

Caddy 的配置核心是Caddyfile，它不是 JSON/YAML，而是一种声明式 DSL。对于单站点 HTTPS，最简配置只需三行：

# /etc/caddy/Caddyfile example.com { reverse_proxy localhost:3000 }

将example.com替换为你的真实域名（如myblog.example.net），并确保该域名 DNS A 记录已解析到这台 Ubuntu 18.04 服务器的公网 IP。然后：

# 测试配置语法（Caddy v2 的语法校验比 v1 严格得多） sudo caddy validate --config /etc/caddy/Caddyfile # 启动服务 sudo systemctl start caddy # 查看实时日志（重点观察 ACME 流程） sudo journalctl -u caddy -f

你会看到类似日志：

INFO http.acme_client trying to solve challenge {"challenge": "http-01", "domain": "example.com"} INFO tls.obtain certificate obtained successfully {"identifier": "example.com"} INFO http.log.access.log0 handled request {"request": {"method": "GET", "uri": "/", ...}, "status": 200}

这意味着：Caddy 已自动完成域名验证、证书签发、TLS 握手配置，并开始代理请求。整个过程通常在 10-20 秒内完成，无需人工干预。

实操心得：如果日志卡在trying to solve challenge超过 60 秒，99% 是 DNS 解析问题。用dig +short example.com在服务器上执行，确认返回的是你的服务器 IP。切勿在本地电脑上 dig——本地网络环境与服务器不同，结果无效。另外，Let’s Encrypt 的 HTTP-01 挑战要求 80 端口完全开放（无防火墙拦截、无安全组限制），这是另一个高频故障点。

3. Caddy 的 TLS 自动化机制深度拆解：它到底如何“零配置”实现 HTTPS？

很多教程把 Caddy 的 HTTPS 自动化描述为“魔法”，但作为一线运维，我们必须知道魔法背后的齿轮如何咬合。Caddy v2 的 TLS 自动化不是黑箱，而是一套精密协同的模块化流程，其核心在于ACME 协议的客户端实现与Linux 内核网络栈的深度集成。

3.1 ACME 协议在 Caddy 中的四阶段生命周期

Let’s Encrypt 使用 ACME（Automatic Certificate Management Environment）协议自动化证书管理。Caddy 内置的 ACME 客户端将整个流程分为四个不可分割的阶段：

这个流程之所以能在 Ubuntu 18.04 上“开箱即用”，是因为 Caddy 将所有阶段所需的组件全部静态编译进二进制：Go 的crypto/tls库、ACME 协议客户端、HTTP/2 服务器、甚至用于生成 CSR 的 RSA/ECC 密钥对生成器。它不调用openssl命令，不读取/etc/ssl/certs，不依赖certbot的 Python 运行时——这正是它能完美规避 Ubuntu 18.04 上 OpenSSL 版本碎片化问题的根本原因。

3.2 TLS 1.3 与密码套件的硬编码安全基线

Caddy v2.8.4 在编译时，将 TLS 参数固化为以下基线（可通过caddy adapt --pretty查看内部 JSON 配置）：

"tls": { "connection_policies": [ { "match": { "sni": ["*"] }, "alpn": ["h2", "http/1.1"], "protocols": ["1.3"], "cipher_suites": [ "TLS_CHACHA20_POLY1305_SHA256", "TLS_AES_256_GCM_SHA384", "TLS_AES_128_GCM_SHA256" ], "curve_preferences": ["X25519", "P256"] } ] }

这意味着：

• 强制 TLS 1.3：Ubuntu 18.04 的内核和 OpenSSL 1.1.1 原生支持 TLS 1.3，Caddy 直接启用，禁用所有旧协议（TLS 1.0/1.1），彻底规避 CVE-2016-2183（Sweet32）等基于块密码的攻击。
• ChaCha20 优先：在移动网络或弱 CPU 设备上，ChaCha20 比 AES-GCM 更快，且抗侧信道攻击能力更强。Caddy 将其置于密码套件列表首位，确保客户端优先协商。
• X25519 密钥交换：比传统的 P-256 椭圆曲线更快、更安全，且无专利风险。

这些参数不是配置项，而是编译时决策。你无法在 Caddyfile 中“降级”到 TLS 1.2，因为代码里根本没有实现——这看似是限制，实则是安全工程的最佳实践：把“错误选项”从菜单里拿掉，比教育用户“不要选错”更可靠。

3.3 证书自动续期的静默守护机制

Let’s Encrypt 证书有效期为 90 天，Caddy 的续期不是简单的 cron 任务。它采用基于事件的主动轮询：

• Caddy 在内存中维护一个证书到期时间表；
• 当检测到某证书将在 24 小时内过期时，它会立即触发 ACME 续期流程；
• 续期过程与首次签发完全一致，但复用已有的账户密钥和域名验证状态（ACME 协议支持revoke和renew）；
• 新证书获取成功后，Caddy 在毫秒级内完成 listener 的证书热替换，零连接中断。

你可以通过sudo caddy list --certificates查看所有已管理证书的详细信息，包括not_after（到期时间）、issuer（颁发者）、key_type（密钥类型）。这个命令的输出，就是 Caddy TLS 自动化系统的实时健康快照。

提示：如果你在journalctl -u caddy中看到renewing certificate日志，不必惊慌——这是正常心跳。Caddy 的续期成功率接近 100%，远高于手动certbot renew（后者常因 crontab 权限、路径、环境变量问题失败）。这也是为什么我们说 Caddy 把“HTTPS 运维”变成了“HTTPS 不存在”。

4. 生产级加固：在 Ubuntu 18.04 上构建抗扫描、防爆破、可审计的 Caddy 服务

一个能自动 HTTPS 的网站，离“生产可用”还有巨大鸿沟。Ubuntu 18.04 作为长期服役的系统，其内核和网络栈存在已知的边界条件缺陷（如 TCP SYN 队列溢出、TIME_WAIT 连接堆积），必须针对性加固。

4.1 内核网络参数调优：应对高并发连接冲击

Ubuntu 18.04 默认的net.ipv4.tcp_fin_timeout = 60和net.ipv4.ip_local_port_range = 32768 60999在面对爬虫、扫描器或突发流量时极易耗尽端口。需在/etc/sysctl.conf中追加：

# 加快 TIME_WAIT 连接回收（防止端口耗尽） net.ipv4.tcp_fin_timeout = 30 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_tw_recycle = 0 # Ubuntu 18.04 必须设为 0，否则与 NAT 冲突 # 扩大本地端口范围（应对大量 outbound 连接） net.ipv4.ip_local_port_range = 1024 65535 # 提升连接队列容量（防 SYN Flood） net.core.somaxconn = 65535 net.core.netdev_max_backlog = 5000 # 启用快速重传（降低丢包影响） net.ipv4.tcp_fastopen = 3

执行sudo sysctl -p生效。这些参数不改变 Caddy 行为，但让底层网络栈能承载更高强度的 TLS 握手压力——毕竟每个 HTTPS 连接都始于三次握手和 TLS 握手，它们消耗的是内核资源，而非 Caddy 进程内存。

4.2 Caddyfile 高级配置：添加 WAF 基础层与访问控制

Caddy 本身不是 WAF，但其http.handlers模块可构建轻量级防护层。在/etc/caddy/Caddyfile中扩展：

example.com { # 1. 速率限制：防暴力探测和爬虫 @bad_ua { header User-Agent "sqlmap|nikto|dirbuster|wget|curl" } respond @bad_ua "Forbidden" 403 # 2. 路径保护：隐藏敏感接口 @admin_path { path /wp-admin/* /wp-login.php /phpmyadmin/* } respond @admin_path "Not Found" 404 # 3. TLS 强制重定向（确保所有流量走 HTTPS） redir https://{host}{uri} permanent # 4. 反向代理到你的应用（如 Node.js） reverse_proxy localhost:3000 { # 健康检查：每 30 秒探测后端 health_uri /health health_interval 30s # 超时设置：避免长连接拖垮 Caddy transport http { read_timeout 30s write_timeout 30s idle_timeout 5m } } }

这段配置实现了：

• UA 黑名单拦截：直接拒绝已知扫描工具的请求，减少日志噪音和 CPU 开销；
• 路径混淆：返回 404 而非 403，让攻击者无法确认后台是否存在 WordPress 或 phpMyAdmin；
• 永久重定向：redir ... permanent发送 HTTP 301，被浏览器和搜索引擎永久缓存，比 JavaScript 重定向更可靠；
• 反向代理健壮性：health_uri让 Caddy 主动探测后端健康状态，自动剔除宕机实例；transport超时防止后端卡死导致 Caddy 连接池耗尽。

4.3 日志审计与故障定位：建立可追溯的 TLS 事件链

Caddy 默认日志只记录访问，但生产环境需要关联 TLS 事件。在 Caddyfile 中添加结构化日志：

{ # 全局日志配置：JSON 格式，便于 ELK 或 Loki 收集 log { output file /var/log/caddy/access.log { roll_size 100MiB roll_keep 10 } format json } } example.com { # 访问日志包含 TLS 详细信息 log { format json { time_iso8601 request_remote_ip request_method request_uri request_proto response_status response_size duration tls_version tls_cipher_suite tls_client_hello_server_name } } # 错误日志单独存放 log /var/log/caddy/error.log { level error } reverse_proxy localhost:3000 }

重启后，/var/log/caddy/access.log中每条记录形如：

{ "time_iso8601": "2024-06-15T14:22:33.123Z", "request_remote_ip": "203.0.113.42", "request_method": "GET", "request_uri": "/", "request_proto": "HTTP/2", "response_status": 200, "response_size": 12345, "duration": 0.045, "tls_version": "1.3", "tls_cipher_suite": "TLS_CHACHA20_POLY1305_SHA256", "tls_client_hello_server_name": "example.com" }

实操心得：当你看到tls_version字段稳定为1.3，tls_cipher_suite为TLS_CHACHA20_POLY1305_SHA256，就证明 Caddy 的 TLS 自动化不仅工作，而且工作在最优状态。如果出现tls_version: "1.2"，说明客户端（如老旧 Android WebView）不支持 TLS 1.3，Caddy 会优雅降级——这正是它“自动化”而非“强制”的智慧：安全基线由服务端定义，兼容性由协议协商保障。

5. 故障排查实战：从 “unexpected status 404 not found” 到 “failed to create ssl/tls secure channel” 的完整归因链

网络热词中反复出现的unexpected status 404 not found、failed to create ssl/tls secure channel、the client failed to negotiate a tls connection等错误，表面看是客户端报错，根源却深埋在 Ubuntu 18.04 与 Caddy 的交互细节中。下面还原一次真实排障全过程。

5.1 现象：客户端报unexpected status 404 not found，但 Caddy 日志无记录

某天客户反馈：“用手机浏览器打不开网站，显示 404”。你登录服务器，curl -I http://example.com返回301 Moved Permanently，curl -I https://example.com却返回404 Not Found，且journalctl -u caddy中没有任何访问日志。

归因链：

1. curl -I http://...成功 → 证明 Caddy 正在监听 80 端口，HTTP 重定向工作；
2. curl -I https://...失败且无日志 → 证明请求根本未到达 Caddy，被系统层拦截；
3. 检查sudo ss -tlnp | grep :443，发现无进程监听 443；
4. 执行sudo systemctl status caddy，显示active (running)，但ps aux | grep caddy发现进程 PID 与 systemd 记录不符；
5. 最终定位：/etc/caddy/Caddyfile中域名拼写错误（exmaple.com），Caddy 启动时因配置错误 fallback 到默认监听:443，但该监听器无匹配域名，故静默丢弃所有请求。

解决方案：

• 永远用sudo caddy validate --config /etc/caddy/Caddyfile验证配置；
• 在 Caddyfile 顶部添加debug指令，启动时输出详细解析日志；
• 使用sudo caddy run --config /etc/caddy/Caddyfile --adapter caddyfile替代systemctl start进行调试。

5.2 现象：Windows 客户端报failed to create ssl/tls secure channel

客户用 .NET Framework 4.6.1 开发的桌面程序，调用https://example.com/api时抛出此异常。curl -v https://example.com在 Ubuntu 服务器上一切正常。

归因链：

1. Windows .NET Framework 4.6.1 默认 TLS 版本为 1.0，而 Caddy 强制 TLS 1.3；
2. 但 Caddy 会协商降级，为何失败？抓包发现客户端发送的ClientHello中supported_versions扩展为空；
3. 追查得知：.NET Framework 4.6.1 需显式启用 TLS 1.2，代码中需添加ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;；
4. 更深层原因：Ubuntu 18.04 的ca-certificates包版本过旧（20180409），缺少 Let’s Encrypt 的 ISRG Root X1 交叉签名证书，导致部分老客户端无法构建信任链。

解决方案：

• 更新 CA 证书：sudo apt update && sudo apt install --only-upgrade ca-certificates；
• 在 Caddyfile 中显式指定证书链（虽非常规，但可解决极端兼容问题）：

  example.com { tls /etc/letsencrypt/live/example.com/fullchain.pem /etc/letsencrypt/live/example.com/privkey.pem }

5.3 现象：gnutls recv error (-110): the tls connection was non-properly terminated

此错误常见于使用 GnuTLS 库的 Linux 客户端（如某些嵌入式设备、旧版 curl）。错误码-110对应GNUTLS_E_UNEXPECTED_PACKET_LENGTH，本质是 TLS 握手过程中，一方提前关闭了连接。

归因链：

1. Caddy 的 TLS listener 在收到非法 ClientHello 时，会立即关闭 TCP 连接（符合 RFC）；
2. 但 GnuTLS 的错误处理逻辑将“连接被对方关闭”解释为“协议错误”，而非“连接终止”；
3. 根本原因是 Caddy 的 TLS 1.3 实现与 GnuTLS 3.5.x（Ubuntu 18.04 默认）的握手消息解析不兼容。

解决方案：

• 升级 GnuTLS（不推荐，破坏系统稳定性）；
• 推荐方案：在 Caddyfile 中临时启用 TLS 1.2 兼容模式：

  example.com { tls { curves x25519 secp256r1 } # 此配置强制 Caddy 在 TLS 1.3 握手失败时，尝试 TLS 1.2 回退 reverse_proxy localhost:3000 }

提示：所有这些故障，最终都指向同一个结论——Caddy 的自动化 TLS 不是“免配置”，而是“配置收敛”。它把原本分散在 OpenSSL、Nginx、certbot、cron、sysctl 中的上百个参数，收敛为 Caddyfile 中的几行声明。排障的本质，是理解这些声明在 Ubuntu 18.04 底层的映射关系。当你能说出tls { curves x25519 }如何翻译成SSL_CTX_set1_curves_list(ctx, "X25519:P-256")，你就真正掌握了这套系统。

6. 从 Ubuntu 18.04 到现代基础设施：Caddy 部署模式的演进与迁移路径

Ubuntu 18.04 已于 2023 年 4 月结束标准支持，2028 年 4 月才结束扩展安全维护（ESM）。这意味着：你现在部署的 Caddy 服务，未来五年内仍需持续运行，但底层 OS 不再接收常规更新。如何让这套“古老”系统上的 Caddy 服务，平滑过渡到现代架构？我的经验是分三步走。

6.1 第一阶段：容器化封装（立即执行）

不要重装系统，而是用 Docker 将 Caddy 与应用一起打包。Ubuntu 18.04 的内核（4.15）完全支持 Docker 20.10+，且caddy:2.8.4官方镜像已针对该内核优化：

# Dockerfile FROM caddy:2.8.4-alpine COPY Caddyfile /etc/caddy/Caddyfile COPY ./myapp /srv/myapp EXPOSE 80 443

构建并运行：

docker build -t my-caddy-app . docker run -d \ --name caddy-prod \ --restart=unless-stopped \ -p 80:80 -p 443:443 \ -v /etc/letsencrypt:/data/caddy \ -v /var/log/caddy:/var/log/caddy \ my-caddy-app

优势：

• Caddy 运行在 Alpine Linux 容器中，完全隔离 Ubuntu 18.04 的老旧库；
• /data/caddy卷持久化证书，升级 Caddy 镜像不丢失证书；
• --restart=unless-stopped确保主机重启后服务自启，比 systemd 更可靠。

6.2 第二阶段：配置即代码（CI/CD 集成）

将 Caddyfile 纳入 Git 仓库，用 GitHub Actions 实现配置变更自动部署：

# .github/workflows/caddy-deploy.yml name: Deploy Caddy Config on: push: paths: ['Caddyfile'] jobs: deploy: runs-on: ubuntu-20.04 # 用新版 runner 构建 steps: - uses: actions/checkout@v4 - name: Copy Caddyfile to server run: scp Caddyfile user@ubuntu18-server:/tmp/Caddyfile - name: Validate and reload on server run: ssh user@ubuntu18-server "sudo cp /tmp/Caddyfile /etc/caddy/Caddyfile && sudo caddy validate --config /etc/caddy/Caddyfile && sudo systemctl reload caddy"

从此，每次git push，Caddy 配置自动生效，且每次变更都有 Git 历史可追溯——这才是真正的“基础设施即代码”。

6.3 第三阶段：渐进式迁移至云原生网关

当业务增长到需要多节点、灰度发布、熔断限流时，Caddy 可作为边缘网关，后端对接 Kubernetes Ingress Controller（如 Traefik）或云厂商 ALB。此时 Caddyfile 变为：

# 边缘 Caddy（Ubuntu 18.04 上） edge.example.com { # 将流量按路径分发到不同后端 @api { path /api/* } reverse_proxy @api http://k8s-api-cluster:80 @web { path / } reverse_proxy @web http://cloudfront-distribution.cloudfront.net # 全局 TLS 管理 tls { dns cloudflare # 使用 Cloudflare API 自动 DNS 挑战 } }

Ubuntu 18.04 不再是单点瓶颈，而是成为云原生架构的“TLS 终结者”——它只做最擅长的事：用最简配置，提供最可靠的 HTTPS 入口。

我的体会是：Caddy 的价值，不在于它多先进，而在于它多“诚实”。它不隐藏复杂性，而是把复杂性封装成可验证、可审计、可迁移的声明。当你在 Ubuntu 18.04 上用 Caddy 部署第一个 HTTPS 网站时，你获得的不仅是一个运行中的服务，更是一套可复制、可演进、可传承的基础设施方法论。这或许就是为什么，十年过去，Caddy 依然是那个“让 HTTPS 变得无聊”的工具——而真正的工程卓越，往往就藏在这种无聊之中。