为什么我开始考虑换掉 Nginx
做了几年个人站长的运维活，Nginx 一直是我的首选反向代理。它的性能没话说，社区资源也丰富，但每次新增一个服务、配一次 HTTPS 证书，流程都差不多：写一段 server block、手动 certbot 申请证书、配置 renew cron、再 reload。循环往复，谈不上痛苦，但确实琐碎。
2025 年底我偶然看到 Caddy 的更新日志，发现它的自动 HTTPS 已经相当成熟了——不仅支持 Let’s Encrypt，还内置了 ZeroSSL 和小型自签证书，真正做到了「开箱即用」。于是我在一台闲置 VPS 上做了对比测试，结果让我认真动了换的心。
Caddy 的核心优势：配置即证书
Caddy 的最大卖点是一个叫「On-Demand TLS」的机制。你在配置文件里写域名，Caddy 会自动为这个域名申请和续期证书，不需要 certbot、不需要 cron、不需要手动干预。整个过程从「写配置 → 申请证书 → 部署证书」变成了「写配置」一步。
举个例子，最简单的反向代理配置只需要三行：
example.com {
reverse_proxy localhost:8080
}
保存为 Caddyfile，启动 caddy run，完事。浏览器访问 example.com，证书自动生效。后续续期也是自动的，不需要任何额外操作。
与 Nginx 配置对比：从 30 行到 3 行
同样的反向代理 + HTTPS 功能，Nginx 的典型配置大概是这个量级：
- server block + listen 443 ssl
- ssl_certificate 和 ssl_certificate_key 指向 certbot 生成的文件路径
- proxy_pass 和一堆 proxy_set_header
- 单独的 certbot renew 定时任务
- reload 的 systemd hook
加起来 20-40 行配置，外加一个 cron job。而 Caddy 把这些全部压缩到了上面那三行里。
实际部署中的几个细节
换到 Caddy 并不是一键迁移，还是有一些要注意的点：
- DNS 解析必须在先 ：Caddy 申请证书时需要验证域名所有权，DNS 的 A 记录必须提前指向服务器 IP，否则证书申请会失败。
- 端口 80 和 443 要开放 ：ACME 协议的 HTTP-01 和 TLS-ALPN-01 验证方式都需要这两个端口可访问。
- 多站点配置很直观 ：多个域名只需要在 Caddyfile 里并列写多个 site block，每个块可以独立配置 reverse_proxy、文件服务、API 转发等。
- 日志和监控 ：Caddy 的日志格式兼容 Nginx 的 combined 格式，Grafana + Prometheus 的 caddy-exporter 可以直接接入。
性能实测：差距不大，但启动更快
我用 wrk 做了一轮简单压测。在同样的 VPS（2 核 4G）上，Nginx 和 Caddy 都做反向代理到后端 Go 服务，并发 500 连接持续 30 秒：
- Nginx：平均 QPS 4200，P99 延迟 23ms
- Caddy：平均 QPS 3900，P99 延迟 28ms
差距在 10% 左右，对于个人站点来说完全可以忽略。而且 Caddy 的启动时间比 Nginx 快得多——冷启动不到 1 秒，Nginx 通常需要 2-3 秒加载配置和证书文件。
迁移建议
如果你也在维护个人站点或小团队服务，以下是我的迁移路径建议：
- 先在一台测试服务器上装 Caddy，把现有 Nginx 配置逐条翻译成 Caddyfile 格式。
- 用 caddy adapt 命令检查配置是否正确，它会输出 JSON 格式的内部配置，方便排查问题。
- 确认证书自动申请正常后，再在生产环境切换。
- 保留 Nginx 配置文件一段时间，万一需要回退可以快速恢复。
Caddy 不是银弹，对于需要精细调优的大型站点（比如需要 upstream 负载均衡策略、rate limiting、waf 规则），Nginx 依然更灵活。但对于大多数个人项目和中小团队，Caddy 的零配置 HTTPS 和简洁语法已经足够好用，值得一试。
