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 作为一款已进入 EOLEnd-of-Life但仍在大量老旧业务系统中服役的 LTS 版本其内核4.15、OpenSSL1.1.1和 systemd237版本都处于一个微妙的临界点——足够新以支持 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、Lets 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_serviceep /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 使用 ACMEAutomatic Certificate Management Environment协议自动化证书管理。Caddy 内置的 ACME 客户端将整个流程分为四个不可分割的阶段阶段触发条件Caddy 内部动作关键依赖1. 证书需求发现Caddyfile 中出现未加tls internal的域名解析配置标记该域名需要公有证书配置文件语法解析器2. 挑战协商首次启动或证书过期前 30 天向 Let’s Encrypt ACME v2 接口发送newOrder请求获取http-01或dns-01挑战令牌网络连通性443 出站、DNS 解析3. 挑战响应收到挑战令牌后在内存中动态注册一个临时 HTTP handler响应/.well-known/acme-challenge/{token}路径内置 HTTP 服务器、端口 80 监听权4. 证书获取与热加载Let’s Encrypt 验证成功后下载证书链PEM 格式解析为 Go 的tls.Certificate结构体注入运行中的 TLS listener内存安全的证书热替换机制这个流程之所以能在 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.3Ubuntu 18.04 的内核和 OpenSSL 1.1.1 原生支持 TLS 1.3Caddy 直接启用禁用所有旧协议TLS 1.0/1.1彻底规避 CVE-2016-2183Sweet32等基于块密码的攻击。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.3tls_cipher_suite为TLS_CHACHA20_POLY1305_SHA256就证明 Caddy 的 TLS 自动化不仅工作而且工作在最优状态。如果出现tls_version: 1.2说明客户端如老旧 Android WebView不支持 TLS 1.3Caddy 会优雅降级——这正是它“自动化”而非“强制”的智慧安全基线由服务端定义兼容性由协议协商保障。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 Permanentlycurl -I https://example.com却返回404 Not Found且journalctl -u caddy中没有任何访问日志。归因链curl -I http://...成功 → 证明 Caddy 正在监听 80 端口HTTP 重定向工作curl -I https://...失败且无日志 → 证明请求根本未到达 Caddy被系统层拦截检查sudo ss -tlnp | grep :443发现无进程监听 443执行sudo systemctl status caddy显示active (running)但ps aux | grep caddy发现进程 PID 与 systemd 记录不符最终定位/etc/caddy/Caddyfile中域名拼写错误exmaple.comCaddy 启动时因配置错误 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 服务器上一切正常。归因链Windows .NET Framework 4.6.1 默认 TLS 版本为 1.0而 Caddy 强制 TLS 1.3但 Caddy 会协商降级为何失败抓包发现客户端发送的ClientHello中supported_versions扩展为空追查得知.NET Framework 4.6.1 需显式启用 TLS 1.2代码中需添加ServicePointManager.SecurityProtocol SecurityProtocolType.Tls12;更深层原因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 握手过程中一方提前关闭了连接。归因链Caddy 的 TLS listener 在收到非法 ClientHello 时会立即关闭 TCP 连接符合 RFC但 GnuTLS 的错误处理逻辑将“连接被对方关闭”解释为“协议错误”而非“连接终止”根本原因是 Caddy 的 TLS 1.3 实现与 GnuTLS 3.5.xUbuntu 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 \ --restartunless-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 镜像不丢失证书--restartunless-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/checkoutv4 - name: Copy Caddyfile to server run: scp Caddyfile userubuntu18-server:/tmp/Caddyfile - name: Validate and reload on server run: ssh userubuntu18-server sudo cp /tmp/Caddyfile /etc/caddy/Caddyfile sudo caddy validate --config /etc/caddy/Caddyfile sudo systemctl reload caddy从此每次git pushCaddy 配置自动生效且每次变更都有 Git 历史可追溯——这才是真正的“基础设施即代码”。6.3 第三阶段渐进式迁移至云原生网关当业务增长到需要多节点、灰度发布、熔断限流时Caddy 可作为边缘网关后端对接 Kubernetes Ingress Controller如 Traefik或云厂商 ALB。此时 Caddyfile 变为# 边缘 CaddyUbuntu 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 变得无聊”的工具——而真正的工程卓越往往就藏在这种无聊之中。