7.2万星的开源Web服务器Caddy，HTTPS从此零配置

Web服务器的配置一直是运维工作里的高摩擦环节。Nginx的配置文件动辄上百行，Apache的.htaccess规则出了名的繁琐。而HTTPS证书的申请、部署、续期，又单独构成一套维护流程。

Caddy出现之后，这两个问题被合并成了一个问题，而且这个问题的答案是"不需要关心"。

自动HTTPS的工作方式

Caddy的核心设计是"默认启用HTTPS"。这不是宣传语，而是代码级别的行为：启动后，Caddy自动向Let’s Encrypt或ZeroSSL申请TLS证书，自动完成域名验证，自动续期，自动处理OCSP装订。整个过程不需要手动操作，配置文件里不需要写任何证书相关的段落。

更少见的设计是，Caddy还能为内部域名和IP地址自动签发证书，通过内置的本地CA来完成。这个能力在微服务架构中很实用，内部服务之间的通信也能做到加密传输。

对于多实例部署场景，Caddy的证书管理模块可以在集群中协调，避免多个节点同时申请证书触发CA的速率限制。

Caddyfile：三行配置跑一个站点

自动HTTPS是Caddy的标志性能力，而Caddyfile是它易用性的根基。

一个反向代理配置，只需要三行：

example.com
reverse_proxy localhost:3000

Caddy会自动为example.com申请证书，启用HTTPS，把流量转发到本地3000端口。同样的功能在Nginx里通常需要二十到三十行配置，其中至少一半用于处理SSL证书路径和加密参数。

在规模增大的情况下，Caddy也提供原生JSON配置和API动态配置。通过API在线修改配置、热加载，这些企业场景的需求都有对应的方案。

Go语言与模块化架构

Caddy由Matthew Holt在2014年大学期间开始开发，用Go语言编写。选择Go带来了几个工程上的结果：

编译后的二进制文件没有外部依赖，连libc都不需要，可以直接部署到任何Linux服务器。单文件部署对容器化场景天然适配。Go的内存安全特性也比C语言系的Web服务器提供了更多保障。

架构上，Caddy被定义为一个"服务器平台"，而不只是一个HTTP服务器。它的模块系统允许按需扩展功能，HTTP和TLS这两个核心能力本身也是以模块形式存在的。这种设计让Caddy能同时支持HTTP/1.1、HTTP/2和HTTP/3，不需要额外编译步骤。

生产环境的验证

Caddy的README给出了一些数据：已处理数万亿次请求，管理了数百万个TLS证书，在生产环境中支撑过数十万个站点。

README中还提到一个特性：当其他服务器因TLS证书过期或OCSP服务不可用而宕机时，Caddy能在证书相关故障中保持运行。这是通过后台的证书健康检查和故障隔离机制实现的。

Caddy在GitHub上积累了超过7.2万颗星，是Go语言生态中Star数最高的Web服务器项目之一。

适用场景

个人项目和小团队，Caddyfile的简洁配置几乎零学习成本。团队如果在用Go语言做基础设施，Caddy的模块系统可以深度集成。对于追求自动化运维的团队，API驱动的配置和自动证书管理能省去大量重复的维护操作。

不过Caddy从2014年至今一直在快速迭代，配置文件格式的长期稳定性是需要评估的一个方面。

总地来说，Caddy没有重新定义Web服务器，它只是把HTTPS这件事做到了"默认开启、无需关心"的程度。而这恰好覆盖了大多数场景下最真实的需求。

eb服务器，它只是把HTTPS这件事做到了"默认开启、无需关心"的程度。而这恰好覆盖了大多数场景下最真实的需求。