75,998颗星、154个Release：Caddy如何在2026年重新定义Web服务器的「省心」标准

星眸·GitHub 观察者 技术创作者 2026-09-23 15 阅读

Caddy 靠什么在 NGINX 和 Apache 的夹缝里活到了 2026 年

75,998 颗星、2,554 次提交记录、每三到四周一个版本——这个数字放在 Web 服务器赛道里算不上惊人，但 Caddy 的特别之处在于，它从来没有打算和 NGINX 拼原始性能。它的核心逻辑是：与其让你花三天配证书，不如让每个网站默认都是 HTTPS。

这个逻辑在 2026 年看起来理所当然，但在 2015 年 Caddy 刚出来的时候，这是一个相当激进的赌注。

它到底解决了什么问题

传统 Web 服务器的 HTTPS 部署链条是这样的：先装服务器，再申请证书，再配置证书路径，再设置自动续期，再处理 OCSP stapling，每一步都可能出错，出错了就要熬夜。

Caddy 的答案是：这些全部不要你管。它内置了 CertMagic 库，首次访问时自动从 Let’s Encrypt 或 ZeroSSL 拉证书，后续在后台自动续期，OCSP 响应默认缓存。在 2018 年那次 Let’s Encrypt OCSP 基础设施宕机事件中，主流网站大批倒下，而所有 Caddy 站点完全不受影响——因为 Caddy 缓存了 OCSP 响应，没有依赖外部基础设施。

这个能力后来被写进了 ISRG（Let’s Encrypt 运营方）的官方建议里，Brad Warren 曾公开表示”应该把 Caddy 列为 ACME 客户端的首推选项”，理由是”服务器自己管理证书，比 Apache 和 NGINX 的分离式方案出错的概率低得多”。

技术边界：谁适合用，谁该绕路

适合用 Caddy 的场景：

  • 个人项目、SaaS 初期，不想被证书管理分散精力
  • 内网服务需要 TLS，但不想搭私有 CA
  • 写 PHP 应用：配合 FrankenPHP 可以把 PHP 应用打成单个静态二进制，官方宣称的响应速度比传统 php-fpm 快约 4 倍
  • 需要在多个格式之间切换配置：Caddyfile、JSON、YAML、TOML、NGINX 配置文件都可以作为输入
  • Kubernetes Ingress：Helm 社区有官方 Caddy Ingress Controller，支持自动 HTTPS 和 HTTP/3

不适合的场景：

  • 超高并发场景：Go 的 goroutine 模型处理并发很优雅，但极端吞吐量下 NGINX 仍然更占优势
  • 需要大量第三方模块：NGINX 和 Apache 生态里有海量的运行时加载模块，而 Caddy 的插件需要重新编译二进制
  • 完全隔离的内网环境（air-gapped）：自动证书申请需要访问外部互联网，需要自己搭私有 CA
  • 需要商业级支持合同的大企业：NGINX 有官方商业版，Caddy 只能靠社区

2026 年 v2.11 版本的现状

Caddy 目前处于 v2.11 稳定阶段，最新版本为 v2.11.4（2026 年 6 月 3 日发布），该版本以安全修复为主。需要注意的是，当前版本受 3 个已知 CVE 影响，官方在持续修补。如果你在生产环境中使用 Caddy，建议订阅 GitHub Releases 通知或加入 Caddy 社区论坛 获取版本更新推送。

v2.11 系列从 2025 年 12 月开始推送 beta 版，到 2026 年 2 月进入稳定版通道，总迭代速度保持在每三周一个版本的节奏。2026 年以来的 6 个月里已经发布了 6 个版本，社区维护活跃度没有明显衰退。

配置体验：Caddyfile 的真实手感

Caddy 的配置文件有两套语法：JSON 和 Caddyfile。对于大多数场景，Caddyfile 是更推荐的选择——一个最简可用的静态站点配置只需要两行：

localhost
respond "Hello, world!"

而生产可用的反向代理+HTTPS 配置：

example.com {
    reverse_proxy /api/* localhost:9000
    encode gzip
    tls admin@example.com
}

JSON 模式的真正价值在于运行时配置变更：Caddy 提供了一套完整的 Admin API，可以在不重启服务的情况下修改配置，这对于需要动态调整路由规则的场景很有用。

性能数据：不要期待奇迹

Caddy 官方对自己的定位是”足够快”，而不是”最快”。Go 的 goroutine 调度在处理大量并发连接时表现良好，但受 Go 运行时开销限制，极限吞吐量一般低于经过 C 语言深度优化的 NGINX。

内存占用方面，Caddy 在空闲状态下通常比 NGINX 稍高，但差距不大。优势在于内存安全性：整棵树用 Go 编写，不依赖 OpenSSL 等 C 语言组件，从根本上规避了 Heartbleed 类型的安全漏洞。

横向对比：它真的值得换吗

如果你目前在用 NGINX 或者 Apache，没有必要为了换而换。Caddy 的核心价值在于降低 HTTPS 的运维心智负担，对于那些证书过期导致事故的团队来说，迁移到 Caddy 的 ROI 是非常清晰的。

对于新项目，特别是以下场景，Caddy 是值得优先考虑的：

  • 内部工具和小服务：不需要背负 NGINX 的配置包袱
  • Docker / Kubernetes 环境：单二进制、无依赖、docker run 直接起
  • 学习环境：两行配置就能让 HTTPS 跑起来，省去理解证书体系的时间成本

下一步建议

如果你想亲自体验，最快路径是：

  1. 从 GitHub Releases 下载对应平台的二进制：https://github.com/caddyserver/caddy/releases
  2. 看官方 Getting Started 文档：https://caddyserver.com/docs/getting-started
  3. 如果你有现有的 NGINX 配置文件，可以用 Caddy 的 config adapter 直接转换：caddy adapt --config nginx.conf --adapter nginx
  4. 需要插件（如额外存储后端）时，用 xcaddy 重新构建：https://github.com/caddyserver/xcaddy

链接集

评论区

0 条评论

登录后可评论。

星眸·GitHub 观察者 15 阅读