caddyserver/caddy

解决什么问题

自己跑 Web 服务器，TLS 证书这件事往往比想象中麻烦：申请、续期、处理 OCSP，ACME 端点一出问题还得排查。用 nginx 或 Apache 时，通常要额外挂 Certbot 加定时任务，而续期悄悄失败往往要等到出事那天才发现。Caddy 的思路是把证书当作服务器自己的职责，默认自动签发和续期，内网域名和 IP 也能通过它内置的本地 CA 覆盖。

有什么不同

和 nginx、Apache 相比，主要差异在配置模型。Caddy 的原生配置是 JSON，通过管理 API 驱动，Caddyfile 是给人看的前端，另有适配器可把 NGINX 配置等格式转过来。API 优先的设计让配置可以热更新而不用重启。另一个不同点是插件需要编译进二进制，用不到的模块不会带进来；nginx 也支持动态模块，但 Caddy 走得更彻底——没有外部依赖，连 libc 都不需要，交付物就是一个文件。HTTP/1.1、HTTP/2、HTTP/3 默认都开。

适合谁

适合为内网或公网服务做 TLS 终结的自托管用户、小团队和平台工程师，尤其是证书流水线不想自己维护的场景。跑大量小站点或容器、自动化签发比精细调参更重要的人会很受用。反过来，如果手里有大量成熟的 nginx 配置、已经形成调优流程，或者需要的模块还没移植过来，就应该先观望：迁移是实打实的工作量，插件生态虽然广，但规模不是 nginx 那个量级。

上手成本

最简单的做法是下载单个二进制放进 PATH，或者用 Go 1.26.0 以上版本从源码构建。要加插件得通过 xcaddy build 重新编译，意味着 CI 里得有 Go 工具链。Linux 上监听低端口可能需要 setcap。许可证是 Apache-2.0，没有商业限制。真正的风险在概念层面：JSON 配置结构和 API 驱动的模型，比一份扁平的 nginx 配置需要更多理解，README 自己也建议所有人先读入门指南。此外 README 偏宣传，迁移细节很少，实际内容都在文档站上。

点评

Caddy 不是新项目。2015 年创建，4301 天后有 78,353 stars，属于有长期积累的成熟项目，不是短期冲榜。近期热度信号不算强：日榜只上过一天，当天 +56 stars；但本月 +2,477、Go 月榜第 2，说明关注度是稳定且广泛的，而非爆发式增长。对一个多年生产使用、把证书管理当核心功能的项目来说，要不要用取决于你认不认同它的配置哲学，而不是它能不能活下去。想要自动 HTTPS 又不想维护多余组件，它值这个位置；已经有深厚 nginx 积累且没有证书痛点，迁移就未必划算。