Caddy 反向代理实战：自动 HTTPS，一条配置顶 Nginx 十行
Caddy 反向代理实战指南：自动 HTTPS、三行 Caddyfile 替代 Nginx 20 行配置，附 4 个常用场景配置模板。
有个事我憋了大半年：之前用 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？评论区聊聊你的理由。
