还在手动配 SSL 证书？这个 75K Star 的 Web 服务器让 HTTPS 自动到起飞

摘要： 配置 HTTPS 证书有多痛苦？申请、验证、续期、重启，每一步都可能出错。Caddy 直接把这些全自动化了

服务器部署好了，网站能访问了，但浏览器地址栏显示「不安全」。你需要配 HTTPS，于是开始折腾 Let's Encrypt，申请证书、验证域名、配置 Nginx、重启服务。好不容易搞定了，三个月后证书过期，网站又挂了。

更糟的是，你有十几个站点，每个都要配证书，每个都要续期。某天凌晨三点，运维电话打来：「证书过期了，网站打不开」。

HTTPS 是必须的，但配证书的过程太痛苦了。

Caddy 的思路很简单：既然 HTTPS 是必须的，那就让它默认开启，全自动，不用你操心。

Github:

github.com/caddyserver…

一句话说清楚

Caddy 是一个用 Go 语言写的 Web 服务器，75.6K Star，4.9K Fork，Apache-2.0 许可证，支持 HTTP/1.1、HTTP/2、HTTP/3，最大卖点是自动 HTTPS——证书申请、续期、配置全自动化，不用手动干预。

它解决了一个什么问题

传统的 Web 服务器（Nginx、Apache）需要手动配置 HTTPS 证书。这个过程有三个痛点：

1. 配置复杂

申请证书要走 ACME 协议，验证域名所有权，配置 Web 服务器响应验证请求，把证书路径写进配置文件。每一步都可能出错，出错了就卡住。

2. 续期麻烦

Let's Encrypt 的证书有效期只有 90 天，你需要配置自动续期脚本，确保它真的在跑，确保续期后能正确加载新证书。很多人续期脚本配错了，自己都不知道，直到证书过期网站挂了。

3. 多站点管理混乱

一个服务器跑多个站点，每个站点都要配证书。证书路径、过期时间、续期任务，管理起来像一团乱麻。

Caddy 的解决方案是：让 Web 服务器自己处理证书。

你只需要告诉 Caddy 你要服务哪个域名，它会自动：

申请证书（通过 Let's Encrypt 或 ZeroSSL）
验证域名所有权
安装证书
配置 HTTPS
自动续期

你什么都不用管，证书的事情 Caddy 全包了。

打个比方：传统 Web 服务器像手动挡汽车，你需要自己换挡、踩离合。Caddy 像自动挡，你只管踩油门，剩下的交给车。

核心功能

1. 自动 HTTPS

这是 Caddy 的核心卖点。配置里写一个域名，Caddy 自动搞定证书。支持 Let's Encrypt 和 ZeroSSL 两个证书颁发机构，还能配置本地 CA 给内网域名用。

2. 多协议支持

默认支持 HTTP/1.1、HTTP/2、HTTP/3。HTTP/3 基于 QUIC，比 HTTP/2 更快，但传统服务器配置起来很麻烦，Caddy 默认就支持。

3. 灵活的配置方式

支持 Caddyfile（简单的文本配置格式）和 JSON（原生配置格式）。Caddyfile 像这样：

1example.com {
2    root * /var/www/html
3    file_server
4}
5

两行搞定一个静态网站。JSON 配置更强大，支持热更新，改了配置不用重启。

4. 热更新配置

通过 API 修改配置，不用重启服务器。对于生产环境来说，这意味着零停机时间。

5. 高度可扩展

模块化架构，可以添加各种功能：反向代理、负载均衡、请求过滤、日志记录。核心保持精简，需要什么加什么。

6. 跨平台

Go 语言写的，编译一次到处跑。Linux、macOS、Windows 都支持，没有外部依赖（连 libc 都不需要）。

7. 静态链接

编译出来是一个单独的二进制文件，拷贝到服务器就能用，不需要安装依赖。

技术架构

Caddy 用 Go 语言写成，这是一个很有意思的选择。

Go 的优势在于：

编译成静态二进制：不需要运行时依赖，部署简单
内存安全：有垃圾回收，但性能接近 C++
跨平台：一次编译到处跑
并发支持好：goroutine 处理高并发很轻松

架构上，Caddy 是一个模块化平台。核心只负责加载配置和管理模块，所有实际功能都由模块提供：

tls 模块：管理证书和 TLS 握手
http 模块：处理 HTTP 请求
其他模块：反向代理、文件服务器、日志等

这种设计让 Caddy 非常灵活。你可以只编译需要的模块，保持二进制文件精简。

技术选型上，Caddy 选择了一个大胆的策略：用 Go 重写整个 Web 服务器，而不是在现有服务器上加功能。这保证了架构的纯净，但也意味着需要从头实现很多功能。

事实证明这个策略是正确的。75.6K Star 和数万亿次 HTTPS 请求的验证，说明 Go 写的 Web 服务器完全能胜任生产环境。

特性	Caddy	Nginx	Apache
语言	Go	C	C
自动 HTTPS	有	无	无
配置方式	Caddyfile/JSON	配置文件	.htaccess
HTTP/3	默认支持	需要模块	不支持
热更新	有	reload	reload
学习曲线	低	中	高
Star	75.6K	25K	14K

优势与不足

优势：

自动 HTTPS：零配置实现 HTTPS，这是杀手级功能
配置简单：Caddyfile 语法直观，两行配置搞定一个网站
HTTP/3 默认支持：不需要额外配置，开箱即用
热更新：改配置不用重启，生产环境友好
跨平台：Go 语言编译，到处运行
社区成熟：75.6K Star，11 年历史，有商业支持

不足：

性能不如 Nginx：Go 写的，性能比 C 写的 Nginx 差一档
模块生态不如 Nginx：Nginx 有几十年的模块积累，Caddy 还在追赶
文档不够完善：部分高级功能需要看源码
企业采用率不如 Nginx：很多公司已经在用 Nginx，迁移成本高
配置格式学习成本：JSON 配置虽然强大，但不如 Caddyfile 直观

前景判断

Caddy 目前处于成熟期，功能完善，社区稳定，已经在生产环境验证多年。

适合的场景：

个人博客、小型网站：配置简单，自动 HTTPS 省心
内网服务：本地 CA 自动生成证书
多站点管理：统一的证书管理
快速原型开发：两行配置搞定一个站点

不适合的场景：

极致性能要求：如果每秒请求量极大，Nginx 更合适
已有 Nginx 基础设施：迁移成本可能不值得
需要大量定制模块：Nginx 的模块生态更丰富

被弃用风险： 极低。有组织维护，有商业支持，社区成熟，已经过了「能不能用」的阶段。

推荐态度： 值得用。如果你是新项目，或者受够了手动配证书，Caddy 是最佳选择。如果你已有 Nginx 基础设施，可以考虑在新项目中尝试 Caddy。

Github:

github.com/caddyserver…

写在最后

Caddy 让我看到了一个趋势：开发者体验正在成为核心竞争力。

Nginx 性能更好、功能更全、生态更丰富，但 Caddy 靠「自动 HTTPS」和「配置简单」就拿下了 75.6K Star。这说明什么？说明很多开发者愿意用一点性能换更好的体验。

这不是个例。越来越多的开源项目在拼「好不好用」，而不是「能不能用」。Vite 比 Webpack 快，但也比 Webpack 好用；Docker 比虚拟机轻，但也比虚拟机好用。

Caddy 的成功告诉我们：把一件痛苦的事情变简单，本身就是巨大的价值。

如果你还在手动配 SSL 证书，试试 Caddy。它可能不会让你的网站变快，但至少让你少操心。

关注

如果这篇文章对你有帮助，关注我。我会持续更新 AI 开源工具、效率工具的深度解读系列，帮你从海量项目中筛选出真正值得用的工具。

《还在手动配 SSL 证书？这个 75K Star 的 Web 服务器让 HTTPS 自动到起飞》是转载文章，点击查看原文。