伟然 的个人博客

在如今的 Web 开发中，Nginx 凭借其强大的生态统治了很久。但如果你厌倦了繁琐的 SSL 证书配置和臃肿的配置文件，那么 Caddy 绝对会让你眼前一亮。它最杀手级的特性就是原生自带免费的自动 SSL 证书申请与续签（Let's Encrypt / ZeroSSL），可以说是真正做到了“开箱即用”。

本文将带你通过两种最主流的方式来部署 Caddy 2：Docker Compose 部署（适合容器化管理）和系统原生部署（适合追求极致性能的物理机或 VPS）。

为什么选择 Caddy？（vs Nginx 痛点对比）

如果你之前用过 Nginx，你一定经历过以下几件“痛苦面具”的事：

1. SSL 证书焦虑：不仅要装 Certbot，写定时任务（Cron）去续签，偶尔还会因为证书过期导致网站“报红”。
2. 配置文件又长又臭：为了配个 HTTPS 反向代理，要在 nginx.conf 里塞满各种 proxy_set_header、SSL 路径和密文套件配置，少个分号（;）系统就起不来。
3. HTTP/3 还要自己编译：想要体验最新的网络协议，还得手动编译 Nginx 源码，极其繁琐。

而作为后起之秀、用 Go 语言编写的 Caddy 2，就是为了彻底解决这些痛点而生的。我们来看看它们直观的差异：

核心优势总结

• 零配置 HTTPS：只要你的域名解析到了服务器，Caddy 在启动时会自动向 Let's Encrypt 或 ZeroSSL 申请证书，并料理好后续的续签。你甚至不需要知道证书文件存在哪里。
• 现代协议降维打击：原生支持 HTTP/2 和 HTTP/3。在网络环境较差（如手机信号切换）的情况下，基于 UDP 的 HTTP/3 能带来明显的访问加速。
• 开发体验（DX）拉满：两三行配置就能完美运行一个带 HTTPS 的反向代理服务，能帮你省下大量的运维时间，让你专注于业务开发。

核心配置：理解 Caddyfile

无论使用哪种部署方式，Caddy 的核心都在于 Caddyfile。它比 Nginx 的语法简单数倍。在开始部署前，我们可以先准备好一个通用的基础配置。

新建一个文件，命名为 Caddyfile：

代码段

# 1. 静态网站托管与反向代理示例
example.com {
    # 自动开启 HTTPS，自动申请证书
    encode gzip zstd # 开启压缩
  
    # 静态文件服务
    root * /var/www/html
    file_server

    # 反向代理（比如代理后台服务）
    handle /api/* {
        reverse_proxy localhost:8080
    }
}

# 2. 多域名与反向代理（如：博客或私有服务）
blog.example.com {
    reverse_proxy 127.0.0.1:3000
}

方案一：使用 Docker Compose 部署

Docker 部署的优势在于隔离性强、迁移方便，非常适合微服务架构或在一台服务器上跑多个独立容器的场景。

我的博客和其余网站就是使用caddy部署的。

仅需三行代码，即可配置好证书+反向代理。

1. 目录结构准备

在服务器上创建项目目录：

Bash

mkdir -p /opt/caddy && cd /opt/caddy
mkdir data config html

• data：用于持久化存储 Caddy 申请到的 SSL 证书，千万不能丢失。
• config：用于存储 Caddy 的运行状态配置。
• html：存放你的静态网站源码。

2. 编写 docker-compose.yml

在 /opt/caddy 目录下创建 docker-compose.yml：

YAML

version: '3.8'

services:
  caddy:
    image: caddy:2-alpine
    container_name: caddy
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp" # 启用 HTTP/3 支持
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - ./html:/var/www/html
      - ./data:/data
      - ./config:/config
    environment:
      - TZ=Asia/Shanghai

3. 启动与管理

将上面写好的 Caddyfile 放到 /opt/caddy 目录下，然后执行：

Bash

# 后台启动
docker compose up -d

# 查看日志（排查证书申请状态）
docker compose logs -f

# 修改 Caddyfile 后，无需重启容器，热重载配置：
docker compose exec -w /etc/caddy caddy caddy reload

方案二：Linux 系统级原生部署

如果你想让 Caddy 直接跑在系统上，减少 Docker 带来的网络损耗，或者配合系统原生的 Systemd 进行管理，可以选择这种方式。本节以 Ubuntu/Debian 系统为例。

1. 安装 Caddy

通过官方专属源进行安装，确保后续可以通过 apt upgrade 自动更新。

Bash

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.p/caddy-stable.list
sudo apt update
sudo apt install caddy

2. 配置与文件路径

在系统级安装中，Caddy 会默认创建 caddy 用户组，并生成以下默认路径：

• 配置文件位置：/etc/caddy/Caddyfile
• 系统服务名称：caddy.service

你可以直接编辑默认配置文件：

Bash

sudo nano /etc/caddy/Caddyfile

(注意：如果你的 Caddyfile 引用了本地的网站静态目录，请确保 caddy 用户对该目录有读取权限)

3. 使用 Systemd 管理服务

Caddy 安装后会自动注册为系统服务，你可以直接使用 systemctl 进行控制：

Bash

# 启动 Caddy 并设置开机自启
sudo systemctl enable --now caddy

# 检查运行状态
sudo systemctl status caddy

# 修改 Caddyfile 后，进行平滑热重载（推荐，无停机时间）
sudo systemctl reload caddy

# 查看系统日志
sudo journalctl -u caddy --no-pager | tail -n 50

避坑指南与最佳实践

1. 域名解析先行：Caddy 的自动 SSL 功能依赖于 ACME 挑战。在启动 Caddy 之前，务必确保你的域名已经正确解析到了当前服务器的公网 IP。如果解析未生效，Caddy 会因为频繁申请失败而被 CA 机构触发速率限制（Rate Limit）。
2. 防火墙放行：Caddy 需要同时占用 80 和 443 端口。请确保服务器安全组或 UFW 防火墙已经放行了这两个端口。另外，Caddy 原生支持 HTTP/3，建议同时放行 443/UDP 端口以获得更快的访问体验。
3. 配置热重载：无论是 Docker 还是系统部署，修改配置后都不要轻易使用 restart。使用 caddy reload 或 systemctl reload 可以在不中断现有连接的情况下秒级应用新配置。

总结

• 如果你追求环境隔离、快速迁移、容器化生态，直接无脑选择 Docker Compose 方案。
• 如果你追求极致性能、更低的资源开销、喜欢传统的 Linux 运维模式，那么 Systemd 系统部署 会是你的菜