Caddy 反向代理实战：自动 HTTPS，一条配置顶 Nginx 十行

有个事我憋了大半年：之前用 Nginx 给 vpnt.top 配 HTTPS，acme.sh 写 crontab、证书路径要手动指定、location 块层层嵌套……每次给新服务加反代都像在翻一座山。上个月我把整个站切到了 Caddy，世界清静了。自动 HTTPS、零配置反向代理、一条 Caddyfile 搞定一个站——这不是广告，是真实体验。

一、Caddy 是什么？和 Nginx 有什么区别？

一句话：Caddy 是一个内置自动 HTTPS 的 Go 语言 Web 服务器。

和 Nginx 比起来，它的核心优势就一条——你不用再管证书了。Caddy 会自动申请 Let’s Encrypt 证书、自动续签、自动重定向 HTTP → HTTPS。你只需要告诉它域名和端口，剩下的它全包了。

用 Nginx 配一个反代 + SSL 是什么体验？

# Nginx — 将近20行配置
server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate /etc/nginx/certs/fullchain.pem;
    ssl_certificate_key /etc/nginx/certs/privkey.pem;

    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

server {
    listen 80;
    server_name example.com;
    return 301 https://$server_name$request_uri;
}

Caddy 呢？三行搞定：

# Caddyfile
example.com {
    reverse_proxy localhost:3000
}

就这？就这。Caddy 自动检测你的域名、自动向 Let’s Encrypt 申请证书、自动配置 HTTPS、自动 301 跳转。你连 ssl_certificate 都不用写。

二、安装 Caddy

Caddy 官方提供一键安装脚本：

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.d/caddy-stable.list
sudo apt update && sudo apt install caddy

装完验证：

caddy version
# 输出: v2.11.x h1:...

Caddy 默认已配置为 systemd 服务，开机自启。装完就能用。

三、实战：4 个最常用的反向代理场景

场景 1：静态网站托管

如果你有个纯静态站点（Hugo / VuePress / 手写 HTML），这是最简单的配法：

blog.example.com {
    root * /var/www/blog
    file_server
    encode gzip
}

root * 指定网站根目录，file_server 开启文件服务，encode gzip 开启压缩。HTTPS 自动就绪。

场景 2：反代本地的 Web 服务（最常用）

这是 Caddy 的看家本领。你的 Docker 容器内网跑着某个服务，想通过域名对外暴露：

miniflux.example.com {
    reverse_proxy localhost:8080
}

vaultwarden.example.com {
    reverse_proxy localhost:8081
}

一条 reverse_proxy 就搞定。我 VPS 上跑了 Miniflux（RSS 阅读器）、Alist（云盘聚合）、Uptime Kuma（监控面板），每个都是这种配法——加域名、写一行反代、重启 Caddy，全程不超过 30 秒。

场景 3：路径转发（一个域名多个服务）

如果你域名有限，可以一个域名加路径前缀区分不同服务：

home.example.com {
    reverse_proxy /rss/* localhost:8080
    reverse_proxy /files/* localhost:8081
    reverse_proxy /monitor/* localhost:3001
    reverse_proxy / localhost:8090
}

需要注意：路径优先级是从精确到模糊，最后一个 / 是兜底规则，所有不匹配的路径都走它。

场景 4：带基本认证的反代

有些内部工具不想公开给全世界，加个密码锁：

private.example.com {
    basicauth {
        admin $2a$14$hash_here
    }
    reverse_proxy localhost:8080
}

用 caddy hash-password 生成密码 hash：

caddy hash-password --plaintext "你的密码"

四、Caddyfile 的正确操作姿势

Caddy 的配置文件叫 Caddyfile，默认放在 /etc/caddy/Caddyfile。几个运维要点：

• 修改后重载配置：systemctl reload caddy（热重载，不会断连）
• 检查配置语法：caddy validate（在 Caddyfile 所在目录运行）
• 查看运行日志：journalctl -u caddy -n 50 -f
• 查看访问日志：需要在 Caddyfile 里手动配置 log 指令才会写日志文件

五、对比总结：我应该用 Nginx 还是 Caddy？

答这个问题之前，先说我的结论——新项目无脑 Caddy，老项目没必要迁移。

对比项	Nginx	Caddy
配置难度	中等，location 层层嵌套	极简，一行反代
HTTPS 配置	acme.sh + crontab + 证书路径	内置自动 HTTPS
性能	极致优化，久经考验	足够好，Go 标准库水准
模块生态	极其丰富	中等（可在官网下载带插件的版本）
学习成本	需要花时间背指令	30 分钟上手
适合场景	高并发、复杂路由、老手	个人项目、中小站点、新手

一句话：如果你在搭个人博客、自建服务、小项目——别犹豫了，用 Caddy。省下的时间够你多写几篇博客。

六、踩坑记录

坑 1：端口被占用

Caddy 默认监听 80 和 443。如果你 VPS 上还跑着 Nginx 或其他 Web 服务器，端口冲突会直接启动失败。systemctl status caddy 能看报错。

坑 2：自动 HTTPS 需要 80 端口可达

Caddy 申请 Let’s Encrypt 证书时，会通过 80 端口做 HTTP 验证。如果 80 被防火墙挡住了，证书申请会失败。检查 UFW 是否允许 80 和 443。

坑 3：路径转发踩坑

后端服务收到的请求路径带了前缀。比如你配了 /app/* 转发到 localhost:3000，后端会收到 /app/api/login 而不是 /api/login。Caddy v2.8+ 的 handle_path 指令可以自动去掉匹配的前缀：

home.example.com {
    handle_path /app/* {
        reverse_proxy localhost:3000
    }
}

七、写在最后

Caddy 不是要取代 Nginx——Nginx 已经是最好的 Web 服务器之一，性能极限、生态完善。但 Caddy 解决了一个 Nginx 从来不愿意解决的问题：把 HTTPS 的门槛降到零。

我身边很多朋友不搞自建不是因为不会，而是因为 “配证书太麻烦了”。Caddy 把这个障碍直接移除了。2026 年的个人站长/自建玩家，与其花时间配 acme.sh + crontab，不如把精力花在真正有价值的地方。

你有在用 Caddy 吗？或者还在坚守 Nginx？评论区聊聊你的理由。