Caddy 反向代理从入门到实战：一行配置搞定 HTTPS

原创。从零开始学习 Caddy 反代配置：单站点、多服务、Docker 部署到生产环境最佳实践，零运维自动 HTTPS。

为什么是 Caddy 而不是 Nginx

如果你配置过 Nginx 的反向代理，你一定经历过这些：

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        ...
    }
}

然后还要写 certbot 脚本、配 cron 定时续期、处理证书过期告警。

Caddy 的版本是这样的：

example.com {
    reverse_proxy localhost:3000

两行。HTTPS 自动。证书自动申请、自动续期。

这不是「偷懒」，而是重新思考了一个问题：反向代理的核心功能是什么？是路由流量。证书管理是一个基础设施问题，不应该交给每个开发者手动处理。

Caddy 的核心优势

最关键的是那句：Caddy 默认安全。你不需要记住「我是不是忘了开 HTTPS」——Caddy 知道域名就会自动申请证书。

快速上手：三种配置方式

1. 命令行（最简单）

如果你只是想快速测一下：

caddy reverse-proxy --from :2080 --to :9000

把 2080 端口的流量转发到 9000。试试看：

curl -v 127.0.0.1:2080

加个域名就自动 HTTPS：

caddy reverse-proxy --from example.com --to :9000

适合临时调试和开发环境。

2. Caddyfile（推荐）

在项目根目录创建 Caddyfile：

:2080
 
reverse_proxy :9000

启动：

caddy run

修改配置后热加载：

caddy reload

3. HTTPS 域名配置

把第一行改成你的域名：

example.com
 
reverse_proxy :9000

Caddy 会自动去 Let's Encrypt 申请证书。前提是 DNS 记录已经指向你的服务器，并且 80 和 443 端口可以公网访问。

如果需要绑定低端口（80/443），在 Linux 上可以通过 setcap 来避免以 root 运行：

sudo setcap cap_net_bind_service=+ep $(which caddy)

实战：多服务路由

一个服务器上跑多个服务——这可能是最常见的场景。

子域名路由

# 前端应用
app.example.com {
    reverse_proxy localhost:3000
}
 
# API 服务
api.example.com {
    reverse_proxy localhost:8080
}

每个子域名独立证书、独立配置。Caddy 会自动为每个域名申请对应的证书。

路径路由

如果你喜欢用一个域名加路径区分服务：

example.com {
    # API 请求转发到后端
    handle_path /api/* {
        reverse_proxy localhost:8080
    }
 
    # 其他请求走前端
    handle {
        reverse_proxy localhost:3000
    }
}

handle_path 会剥离路径前缀再转发，比如 /api/users 变成 /users 再发到后端。handle 则是一个兜底匹配。

至关重要的转发头

如果你发现后端应用拿不到客户的真实 IP，或者 HTTPS 检测总是重定向循环，问题通常在这里：

app.example.com {
    reverse_proxy localhost:3000 {
        header_up X-Forwarded-For {http.request.remote.host}
        header_up X-Forwarded-Proto {http.request.scheme}
        header_up Host {http.request.host}
    }
}

这三行告诉后端：

• X-Forwarded-For：客户端的真实 IP
• X-Forwarded-Proto：原始请求协议（http 还是 https）
• Host：客户请求的原始域名

大部分现代 Web 框架（Rails、Django、Next.js 等）都需要这些头才能正确生成 URL 和识别客户端。

Docker 生产部署

以下是面向生产的 Docker Compose 配置：

version: "3.8"
 
services:
  caddy:
    image: caddy:latest
    container_name: caddy_proxy
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"  # HTTP/3
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data    # 证书持久化
      - caddy_config:/config
 
  my-app:
    image: your-app:latest
    container_name: my_app
    restart: unless-stopped
    # 不需要暴露端口到宿主机！
    expose:
      - "8000"
 
volumes:
  caddy_data:
  caddy_config:

这里有一个容易忽略的细节：caddy_data 卷必须持久化。否则每次重启容器都要重新申请证书，Let's Encrypt 有速率限制（每周 50 个证书），频繁重建会导致你被暂时封禁。

对应的 Caddyfile（在 Docker 网络内，用服务名通信）：

app.example.com {
    reverse_proxy my-app:8000
}

Docker Compose 默认创建一个内部网络，容器之间可以通过服务名互相访问。Caddy 和 my-app 之间的通信不需要暴露端口到宿主机，更安全。

性能表现

独立测试显示，Caddy v2 在某些反向代理场景下的性能接近甚至超过 Nginx。在默认配置下，Caddy 可以处理约 23 万请求，最大延迟约 21 秒。优化后的 Nginx 大约 32 万请求，延迟约 2.5 秒。

对于个人博客、中小型 SaaS、API 服务来说，Caddy 的性能绰绰有余。如果你在运营亿级流量的服务，确实需要更精细的调优——但到那个规模之前，Caddy 的简洁性带来的运维收益远大于那一点性能差距。

常见问题

Q：需要自己配置证书续期吗？

不需要。Caddy 内置 ACME 客户端，会在证书到期前自动续期。装好就不用管了。

Q：WebSocket 支持吗？

Caddy 自动识别 WebSocket 升级请求，不需要额外配置。直接 reverse_proxy 就好。

Q：一台服务器能跑多个 HTTPS 站点吗？

可以。Caddyfile 里写多个 site block，每个对应一个域名，自动为每个域名申请独立证书。

Q：生产环境建议用哪种部署方式？

有 Docker 环境用 Docker Compose，否则用系统自带的 systemd 服务。两种方式 Caddy 官方都有完善的支持。

写在最后

Caddy 让我想起一个道理：好的工具让正确的事情变得简单，让错误的事情变得困难。

在 Nginx 的世界里，正确配置 HTTPS 需要额外的步骤和知识，很多人就「先不配了」——然后忘了。在 Caddy 的世界里，正确的做法就是默认行为，不需要额外的步骤。

如果你还在手动管理 Nginx 证书配置，或者你的反向代理设置里有超过 50 行配置，试试 Caddy。30 分钟后你可能就回不去了。