关注【索引目录】服务号，更多精彩内容等你来探索！
曾经是 Nginx 的忠实粉丝。它几乎无处不在——个人项目、客户网站、生产服务器。一旦学会了配置文件，它就变得非常实用，而且它非常稳定可靠。
但几年前，我发现了 Caddy。它的设置简单多了。只需一个二进制文件。配置文件实际上可读。而且自动 HTTPS 功能……真的有效。
从那以后我就没再部署过 Nginx。最近，我正在开发UserJot（一个帮助团队收集和管理用户反馈的工具），Caddy 在我们专注于产品的同时，也帮助我们保持了基础设施的简洁。
那一刻
这是 Caddy 中完整的、可用于生产的反向代理配置：
api.myapp.com {
reverse_proxy localhost:3000
}就这样。三行代码。包含 HTTPS。证书自动生成。HTTP/2 已启用。
我第一次看到这个的时候，简直不敢相信。SSL 配置在哪里？密码套件在哪里？证书路径在哪里？
没有。Caddy 自己处理。
真实示例：Node + TypeScript + Hono
让我来演示一下这有多简单。假设你在 3000 端口上运行了一个 Hono API：
import { Hono } from 'hono';
const app = new Hono();
app.get('/api/health', (c) => {
return c.json({ status: 'ok', timestamp: new Date() });
});
app.post('/api/data', async (c) => {
const body = await c.req.json();
// Your business logic here
return c.json({ received: body });
});
export default app;要将其置于具有 HTTPS、自定义域和所有好东西的 Caddy 之后：
-
安装 Caddy（一个命令） -
创建 Caddyfile：
api.yourapp.com {
reverse_proxy localhost:3000
}-
跑步 caddy start
完成。您的 API 现已可用https://api.yourapp.com：
-
自动配置 Let's Encrypt 证书 -
自动 HTTPS 重定向 -
HTTP/2 和 HTTP/3 支持 -
正确的代理标头 -
证书自动续订
让我改变主意的功能
多个域名？只需添加更多区块
在 Caddy 中管理多个域名非常简单。每个域名都有自己的区块，您可以独立配置。需要在管理面板上进行基本身份验证？只需将其添加到该区块即可。想要为不同的子域名设置不同的后端？没问题。
api.yourapp.com {
reverse_proxy localhost:3000
}
app.yourapp.com {
reverse_proxy localhost:3001
}
admin.yourapp.com {
reverse_proxy localhost:3002
basicauth {
admin $2a$14$Zkx19XL...
}
}每个域名都会自动获得专属的 SSL 证书。无需手动管理证书，也无需共享证书。只需干净、独立的配置。
需要负载均衡吗？一行代码
内置跨多个后端服务器的负载均衡功能。Caddy 默认会使用轮询机制自动分配请求，但您也可以选择其他策略，例如最少连接数或 IP 哈希。健康检查功能会确保服务器池中的宕机服务器自动移除。
api.yourapp.com {
reverse_proxy localhost:3000 localhost:3001 localhost:3002 {
lb_policy round_robin
health_uri /health
health_interval 10s
}
}此配置将流量分散到三台后端服务器，每 10 秒检查一次它们的健康状况，并自动停止向任何未通过健康检查的服务器发送流量。无需单独的负载均衡器。
想要通配符证书？简单
需要为您的 SaaS 处理任意子域名吗？也许是 http://customer1.yourapp.com、http://customer2.yourapp.com 等等？通配符证书只需一行代码。Caddy 将从 Let's Encrypt 获取一个通配符证书，并将其用于所有匹配的子域名。
*.yourapp.com {
reverse_proxy localhost:3000
}这对于多租户 SaaS 应用来说非常理想，因为每个客户都有自己的子域名。所有子域名都使用相同的配置。
WebSocket 支持？已经支持了
无需特殊配置，即可使用。Caddy 会自动检测 WebSocket 升级标头并进行妥善处理。无需再翻阅文档寻找合适的代理标头。
实际有效的开发环境设置
这里有一点很有用：您可以使用 .local 域名和 HTTPS 在本地运行完全相同的 Caddy 设置。不再出现localhost:3000与生产环境 URL 不匹配的情况。
首先，将条目添加到您的/etc/hosts：
127.0.0.1 api.myapp.local
127.0.0.1 app.myapp.local然后创建本地的Caddyfile：
api.myapp.local {
reverse_proxy localhost:3000
}
app.myapp.local {
reverse_proxy localhost:3001
}使用监视模式运行 Caddy：
caddy run --watch现在您正在开发：
-
真正的 HTTPS（Caddy 生成本地证书） -
类似生产的 URL -
编辑 Caddyfile 时自动重新加载配置 -
与生产设置完全相同，只是使用 .local 而不是 .com
我开始工作时会运行一次 Caddy，它会在后台处理我的所有服务。更改 Caddyfile 时，Caddy 会自动重新加载。需要添加新服务？添加三行代码，保存，就完成了。
这对于测试 webhook、OAuth 流以及开发中需要正确 URL 和 HTTPS 的任何其他内容都非常有帮助。
UserJot 后端在此运行
在UserJot，我们的整个后端都运行在 Caddy 上。是的，实际操作比这些例子要复杂得多——我们处理客户子域名、动态路由和 API 版本控制。但这个简单的基础却拥有极佳的扩展性。
最初的 3 行配置可以发展成为一个复杂的路由系统，而不会成为 Nginx 配置所面临的维护噩梦。
诚实的比较
Nginx：功能强大，久经考验，但配置复杂，每次更改都感觉有风险。
Apache：请注意，是 2024 年。
Traefik：对于 Kubernetes 来说很棒，但对于其他一切都显得有些过度。
HAProxy：对于负载平衡来说非常棒，但 HTTPS 仍然很痛苦。
Caddy：Just works™。真的。
当 Caddy 可能不正确时
说实话，Caddy 并不是万能的：
-
如果您需要对请求处理的各个方面进行超细粒度的控制 -
如果你每秒处理 10 万个以上的请求（尽管 v2 的速度出奇地快） -
如果你的组织拥有深厚的 Nginx 专业知识和自定义模块
但对于我们另外 95% 的人来说，Caddy 要简单得多。
5分钟即可开始
选项 1：直接安装
# Ubuntu/Debian
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy选项 2：Docker
FROM caddy:alpine
COPY Caddyfile /etc/caddy/Caddyfile您的第一个 Caddyfile
localhost:8080 {
respond "Hello, Caddy!"
}运行caddy run并访问http://localhost:8080。你现在正在运行 Caddy。
挑战
我向你发起挑战：用你最简单的反向代理设置，本周就试用一下 Caddy。只需一项服务。我敢打赌，你会惊讶于：
-
配置有多简单 -
您可以多快做出改变 -
你对 SSL 证书的担忧减少了多少
最后的想法
切换到 Caddy 是一个一直很有效的决定。每次我需要添加新域名或服务，只需两分钟就能搞定，而不需要两个小时的调试时间。
关注【索引目录】服务号，更多精彩内容等你来探索！