Caddy 反向代理配置教程：自动 HTTPS 与多服务统一入口

摘要

自建服务跑到第三个之后，端口就开始不够用了：网盘在 8080，相册在 2283，监控在 3000，每次访问都要记一串数字，而且全是不加密的 HTTP。反向代理解决的正是这个问题——用一个入口按域名分流到不同后端服务，同时统一处理证书。本文用 Caddy 完成这件事，它最大的优势是自动申请和续期 HTTPS 证书，配置文件也比 Nginx 简洁。文中包含安装、单服务代理、多服务分流、WebSocket 支持、访问控制与故障排查。

一、为什么需要反向代理

假设你在一台服务器上部署了三个服务，直接暴露端口访问会遇到这些问题：

• 地址难记，且暴露了内部端口结构。
• 每个服务都要单独在防火墙放通端口，攻击面随服务数量线性增长。
• HTTPS 需要为每个服务单独配置证书，维护成本高。
• 部分服务不支持修改监听端口，两个服务都想用 80 端口时会直接冲突。

反向代理把这些问题收敛到一处：外部只开放 80 和 443，代理层根据请求的域名把流量转发到对应的本地端口，证书也只在代理层管理。

选择 Caddy 而不是 Nginx，主要理由是证书自动化。Caddy 会在首次访问时自动向证书颁发机构申请证书，并在到期前自动续期，不需要额外配置续期任务。配置语法也更紧凑，一个完整的 HTTPS 反向代理只需三行。

Nginx 在复杂路由、精细缓存控制和超大并发调优方面选项更丰富，社区资料也更多。如果你的场景需要大量自定义规则，或团队已有 Nginx 运维经验，继续用 Nginx 是合理的。本文选 Caddy 是因为对自建服务这个场景，它的配置成本明显更低。

二、前置条件

关于域名与备案：如果服务器位于中国内地，域名指向该服务器并通过 80、443 端口提供网站服务，需要先完成 ICP 备案。备案未完成时，可以先用境外或中国香港地域的实例验证配置流程。

DNS 解析需要提前配好。在域名服务商处添加 A 记录，把主机记录指向服务器公网 IP。本文用到两个子域名，添加两条 A 记录：

解析生效后先验证，这一步不通后面全都白做：

dig +short pan.example.com
ping -c 2 pan.example.com

返回的 IP 与服务器公网 IP 一致才能继续。解析通常几分钟内生效，具体取决于 TTL 设置。

三、安装 Caddy

Ubuntu 与 Debian 使用官方软件源：

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
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.d/caddy-stable.list
sudo apt update && sudo apt install -y caddy

安装完成后 Caddy 会以 systemd 服务方式自动启动：

sudo systemctl status caddy --no-pager
caddy version

此时访问服务器公网 IP 应该能看到 Caddy 的默认欢迎页，说明进程已正常监听 80 端口。

如果更倾向容器化部署，也可以用 Docker 运行：

services:
  caddy:
    image: caddy:2-alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy-data:/data
      - caddy-config:/config
    restart: unless-stopped

volumes:
  caddy-data:
  caddy-config:

容器方式要特别注意 caddy-data 卷必须持久化，证书就存在里面。这个卷丢了会导致重启后重新申请证书，而证书颁发机构对同一域名的申请频率有限制，频繁重申可能触发限流，短时间内无法再签发。

四、配置单个服务的反向代理

Caddy 的配置文件位于 /etc/caddy/Caddyfile。先看最小可用配置：

pan.example.com {
    reverse_proxy 127.0.0.1:8080
}

三行完成的事情包括：监听 443 端口、自动申请域名证书、把 HTTP 请求重定向到 HTTPS、将流量转发到本机 8080 端口。

编辑配置并重载：

sudo nano /etc/caddy/Caddyfile
sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy

caddy validate 这一步不要跳过。它在重载前检查语法，避免一个拼写错误导致整个代理服务下线，把所有站点一起带走。

首次访问域名时，Caddy 会向证书颁发机构发起申请，过程通常几秒到几十秒。观察日志确认申请结果：

sudo journalctl -u caddy -f --no-pager

日志中出现 certificate obtained successfully 表示证书已签发。

五、多服务分流与常用配置

实际场景通常需要在一份配置里管理多个服务。Caddyfile 支持多个站点块并列：

# 网盘服务
pan.example.com {
    reverse_proxy 127.0.0.1:8080 {
        header_up X-Real-IP {remote_host}
    }
    request_body {
        max_size 10GB
    }
}

# 相册服务，需要 WebSocket 支持
photo.example.com {
    reverse_proxy 127.0.0.1:2283
    request_body {
        max_size 5GB
    }
}

# 监控面板，限制访问来源
status.example.com {
    @denied not remote_ip 203.0.113.0/24
    respond @denied 403

    reverse_proxy 127.0.0.1:3000
}

几个字段的实际作用：

header_up X-Real-IP 把客户端真实 IP 传给后端。不加这一项，后端服务看到的所有请求都来自代理本身，登录日志和限流功能都会失效。

request_body max_size 控制允许的请求体大小。这是自建网盘和相册最容易踩的坑——默认限制较小时，上传大文件会在中途失败并返回 413，而后端服务日志里往往看不出原因。上传类服务务必按实际需求调大。

WebSocket 在 Caddy 中由 reverse_proxy 自动处理，不需要像 Nginx 那样手写 Upgrade 和 Connection 头。相册、聊天、实时日志这类依赖长连接的服务可以直接工作。

remote_ip 访问控制 适合监控面板、管理后台这类不该对公网开放的服务。上面的写法表示只允许指定网段访问，其他来源返回 403。需要注意这条规则匹配的是直连 IP，如果前面还有一层 CDN 或负载均衡，实际来源会被改写，需要改用其他判断方式。

如果多个子域名转发规则完全一致，可以用通配符减少重复：

*.apps.example.com {
    reverse_proxy 127.0.0.1:8080
}

通配符证书需要通过 DNS 验证方式申请，要求 Caddy 能调用域名服务商的 API，需使用带有对应 DNS 插件的构建版本。配置成本比单域名高，服务数量不多时建议先用逐个域名的方式。

六、验证配置是否生效

改完配置后逐项确认，不要只看浏览器能不能打开。

确认 HTTPS 证书有效且链路完整：

curl -I https://pan.example.com

正常应返回 200 或 302，且没有证书告警。

确认 HTTP 已自动跳转到 HTTPS：

curl -I http://pan.example.com

应返回 301 或 308，Location 头指向 https 地址。

查看证书的签发者与有效期：

echo | openssl s_client -connect pan.example.com:443 -servername pan.example.com 2>/dev/null \
  | openssl x509 -noout -dates -issuer

确认后端真实收到了转发请求，而不是代理返回的错误页：

sudo journalctl -u caddy -n 50 --no-pager | grep pan.example.com

如果服务涉及大文件上传，实际传一个接近上限的文件验证一遍。这类问题在小文件测试中完全不会暴露。

七、常见问题与排查

证书申请失败

按顺序检查：域名解析是否已指向本机，80 端口是否在控制台防火墙或安全组中放通，本机是否有其他进程占用 80 端口。证书颁发机构需要通过 80 端口完成域名归属验证，这个端口关闭时申请一定失败。用以下命令确认端口监听情况：

sudo ss -lntp | grep -E ':(80|443)'

如果反复申请失败多次，先停下来排查，不要持续重试。频繁申请可能触发颁发机构的频率限制，进入冷却期后短时间内无法再签发。

502 Bad Gateway

代理已工作，但后端不可达。确认后端服务正在运行且监听地址正确：

curl -I http://127.0.0.1:8080

一个高频原因是后端只监听在容器内部网络。如果 Caddy 装在宿主机、后端跑在容器里，需要确认容器已把端口映射到宿主机；如果两者都在容器中，应让它们加入同一个 Docker 网络，并用服务名而非 127.0.0.1 作为转发目标——在容器内，127.0.0.1 指向的是容器自己。

上传大文件失败或返回 413

调大对应站点的 request_body max_size。注意后端应用自身可能也有上传大小限制，两处都需要放宽才能生效。

修改配置后没有变化

确认执行了 systemctl reload caddy，并检查 caddy validate 是否报错。语法错误时 Caddy 会拒绝加载新配置，继续沿用旧配置运行，此时页面表现和没改一样。

日志里出现大量陌生域名的请求

公网上有大量扫描流量会用随机域名或 IP 直接请求服务器。可以增加一个默认站点块，对未匹配到任何域名的请求统一返回错误，减少无效日志：

:80, :443 {
    respond 404
}

八、维护建议

备份证书目录：Caddy 默认把证书存放在 /var/lib/caddy 下。迁移服务器时一并复制该目录，可以避免重新申请。容器部署时对应的是持久化卷。

变更前创建快照：调整代理配置属于影响面较大的操作，配置错误会导致所有站点同时不可用。改动前给实例创建一份快照，轻量应用服务器在实例详情页的「快照」页签即可完成，通常 5 分钟内结束且无需关机。回滚时需注意整块系统盘会恢复到快照时间点，之后的数据变更会被清除。

集中管理配置：把 Caddyfile 纳入版本管理，每次改动留下记录。服务数量增加后，可以用 import 指令把配置拆成多个文件分别维护。

关注证书到期提醒：Caddy 会自动续期，但如果域名解析变更或端口被意外关闭，续期会静默失败。建议定期检查证书有效期，或配置一个外部监控做到期告警。

按需收紧访问范围：管理后台、监控面板这类服务不必对全网开放。用 remote_ip 限制来源网段，或叠加基础认证，能显著降低被扫描和爆破的风险。

配好反向代理之后，后续新增的自托管服务只需在 Caddyfile 里追加一个站点块，不必再为端口和证书重复劳动。

如果你还在为多个服务的端口和证书发愁，轻量应用服务器的可视化防火墙管理可以让端口放通这一步更直观；需要更精细的网络与安全组策略时，可以使用云服务器 CVM。