Caddy Web 服务器：Go 单文件 50MB，自动 HTTPS 三行配置搞定

自建网站最烦的不是写页面，是证书。Nginx 要自己去申请证书、配续期定时任务、改完配置还得 reload，一个环节忘了就报红锁，半夜证书过期站点挂掉的事谁都遇到过。Caddy 把这一整套全自动化了：证书申请、续期、HTTP 跳转 HTTPS，全部它在后台自己办，你只管写三行配置。

它是 Go 语言写的现代 Web 服务器，单文件零依赖，Windows 上就是一个 44MB 的 exe，Linux 上一个 47MB 的二进制，拷过去就能跑。静态文件服务、反向代理、负载均衡、PHP 站点它都内置，不用像 Nginx 那样靠编译参数拼功能。我手上这个 6 页的演示站，配置文件只有 11 行，其中还包括一行压缩开关。

我把 Windows 和 Linux（WSL2 Ubuntu）都跑了一遍：Windows 侧从进程拉起到首页返回 200 用了约 190 毫秒，首页连续 10 次请求全在 1 毫秒内返回，gzip 与自定义响应头都正常；Linux 侧同样配置校验通过、四个路径探活全部符合预期（含 404 正确兜底）。下面把过程和数据都摊开。先说结论：把证书当心病的人、想在 Windows 上快速起站的、需要给内网服务套一层反代的，Caddy 都值得直接换上；唯一要掂量的是内存占用和超大规模下 Nginx 生态的差距。

它是什么 / 和 Nginx 差在哪

Caddy 是一个 Go 语言写的 Web 服务器和反向代理，最大的卖点是自动 HTTPS：只要你的站点配置里写了域名，它就自己去申请证书、自己续期、自己把 HTTP 请求跳到 HTTPS，全程不需要你碰 certbot 之类的工具。默认还开了 HTTP/2，配上域名就是 HTTP/3。

和 Nginx 的差别，用三句话讲完：

• 配置量：Caddy 的 Caddyfile 几行搞定一个站点，Nginx 的 server 块加 SSL 配置动辄三四十行。
• 证书：Caddy 全自动，Nginx 要靠外部工具续期。
• 部署：Caddy 是单文件，没有 so 模块、没有编译参数，Nginx 想加功能经常要重编。

它不是 Nginx 的全面替代。单机几万并发、要精细化调优的场景，Nginx 依然更成熟。但对个人站点、内网穿透后的入口、小型项目网关来说，Caddy 的省心程度高一个量级。

我的测试环境

• Windows 11，64 位，直接跑 caddy.exe，配置监听 9080（静态站）和 9081（respond 接口）。
• Linux 侧是 WSL2 Ubuntu，用的是和 Windows 侧同一套演示站与配置，二进制来自包内 linux 目录。
• 演示站是一个 6 页的静态站（首页、文档页、详情页 + 手机版截图对应的三页）。
• 计时方式：进程启动后轮询请求，拿到第一个 HTTP 200 为止；页面耗时用裸 HTTP 请求测，不带浏览器渲染。

安装：Windows

解压后进入 windows 目录，两步走：

caddy.exe version
caddy.exe validate --config Caddyfile

第一行看版本，第二行校验配置。我的输出是 Valid configuration，说明配置文件没问题。然后启动：

caddy.exe run --config Caddyfile

控制台看到 server running 就绪。我这个演示 Caddyfile 全文只有 11 行：

:9080 {
    root * ./site
    encode gzip
    file_server
    header {
        X-Caddy-Test "ok"
    }
}

:9081 {
    respond "hello from caddy respond directive"
}

纯 IP 监听（不带域名）就是上面这样，不碰证书逻辑，起得飞快。真实站点把 :9080 换成你的域名，Caddy 自动走 HTTPS，其他一行不用改。

安装：Linux

包里的 linux 目录是同一个版本的二进制，拷到目标机器后：

chmod +x caddy
mv caddy /usr/local/bin/
caddy version

我在 WSL2 Ubuntu 里实测：把 linux/caddy 拷进测试目录、chmod、validate，从拷贝到 Valid configuration 用了 649 毫秒。启动用 caddy start（后台运行）或 caddy run（前台），探活用 bash 自带的 /dev/tcp 就够了，不依赖 curl：

exec 3<>/dev/tcp/127.0.0.1/9080
printf "GET / HTTP/1.0\r\nHost: 127.0.0.1\r\n\r\n" >&3
head -c 12 <&3

返回 HTTP/1.1 200 就算起站成功。测完记得 caddy stop 并清掉测试目录，别把临时文件留在系统里。

建站上手：三步

1. 写一个 Caddyfile：站域名 + 站点根目录 + file_server，三行就是一个 HTTPS 静态站。
2. 校验：caddy validate --config Caddyfile，把语法错误挡在启动前。
3. 启动：caddy run --config Caddyfile（前台）或 caddy start（后台），首次带域名启动时它会自己去签证书，控制台能看到签发日志。

反向代理也就两行：

example.com {
    reverse_proxy 127.0.0.1:3000
}

把域名换成你的，后端端口换成你的服务端口，完事。这就是它和 Nginx 配置体验的最大差别。

实测数据

• Windows 侧启动到首次 200：约 190 毫秒（进程拉起即含在计时里）。
• Windows 侧首页 10 次连续请求：0~1 毫秒每次，全程无抖动。
• gzip 与自定义响应头：9080 的所有页面上自定义头都正确带上了，压缩按配置生效。
• 404 兜底：不存在的路径返回标准 404，不会白屏。
• 9081 的 respond 指令：纯文本接口按配置原样返回，content-type 正确。
• Linux（WSL2）侧：二进制运行、配置校验通过，四个路径探活符合预期（/、/docs/、/about.html 均 200，/missing.html 404），单次探活 1~4 毫秒。
• Windows 侧启动日志里两个监听口从 using config from file 到 server running 只隔了约 20 毫秒，配置加载本身几乎不花时间。

要说数字之外的感受：它启动快到让你怀疑没启动，curl 一下确认会更踏实。

界面长什么样

一个真实的坑

Linux 侧第一次测启动计时，我用前台方式起 Caddy 再在另一个 shell 里探活，测出来"启动到首次 200"要 10 秒以上，第二遍甚至 20 秒。翻日志才发现：Caddy 本体在写完 server running 之后 100 毫秒内就绪了，慢的是我的测量方式——前台进程占着会话，探活循环被拖住。换 caddy start（它自己 fork 到后台）再探，服务端实际就绪就是亚秒级的事。

教训写在这：测启动速度要区分"服务没就绪"和"你的测量方法在等别的什么"。直接看日志时间戳比盲目轮询靠谱——日志里 server running 和 serving initial configuration 前后只差几毫秒。

这几类人适合，这几类不适合

适合：

• 嫌证书麻烦的个人站长，域名一写全托管。
• 想在 Windows 上直接跑 Web 服务、不想装 WSL 的人，单 exe 天然友好。
• 要给一堆内网服务（监控面板、容器管理、自建 API）套统一入口的人，reverse_proxy 两行一个。
• 小团队内部工具的网关，用一点内存换省心划算。

不适合：

• 单机要扛大流量、需要精细内核参数调优的，Nginx 更合适。
• 依赖 Nginx 生态里特定第三方模块的，Caddy 没有对应的模块体系。
• 内存严格受限的小盒子：Go 运行时底子摆在那，比 C 语言写的轻量服务器吃内存。

常见问题

源码获取

下载后建议先转存到自己网盘再解压，防止分享链接失效后找不回资源。