VPS 上的 Caddy 与 Nginx：配置文件对比

example.com {
    reverse_proxy localhost:3000
}

nginx.conf

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

Nginx 块中的 TLS 行假定 Certbot 已经运行过。对于像上面这样的 HTTP 上游，Caddy 会把传入的 Host 头透传过去，并默认设置 X-Forwarded-For, X-Forwarded-Proto，以及 X-Forwarded-Host 默认情况下。使用 Nginx 时，当上游需要原始主机、协议方案和客户端地址链时，你通常要显式添加代理头。这就是这一权衡的缩影：Caddy 提供了实用的代理默认值，而 Nginx 让更多这类行为交由你显式指定。

静态文件服务：

Caddyfile

example.com {
    root * /var/www
    file_server
}

nginx.conf

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    root /var/www;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}

基本认证，用用户名和密码把所有内容保护起来：

Caddyfile

example.com {
    basic_auth {
        Bob $2a$14$Zkx19XLiW6VYouLHR5NmfOFU0z2GTNmpkT/5qqR7hx4IjWJPDhjvG
    }
    reverse_proxy localhost:3000
}

nginx.conf

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    auth_basic           "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

两个工具都在带外对密码做哈希。Caddy 使用 caddy hash-password；Nginx 使用 htpasswd 来构建 .htpasswd 文件。顺便一提，在当前版本的 Caddy 中，这个指令是 basic_auth 。它原本叫 basicauth ，直到 v2.8.0 将其重命名，正如 Caddy basic_auth 文档中所述，旧教程至今仍让人在这上面栽跟头。

小贴士： Caddyfile 里的那串哈希并不是密码。它是来自 caddy hash-password的 bcrypt 输出。运行该命令，把它打印出来的内容粘贴进去即可。Caddy 拒绝在配置中使用明文密码，这是正确的默认行为，也是初次遇到时的一个小意外。

这些配置本身就说明了问题。Caddy 把 TLS、合理的代理头和一个重定向折叠进寥寥几行；Nginx 则显式而冗长，把每一个旋钮都交到你手上。如果你在 Nginx 上摸爬滚打多年，这份冗长就是肌肉记忆，而那份控制力正是它的意义所在。如果你没有，那 Caddyfile 就是一份你能装进脑子里的配置。实用的要点很简单：Caddy 的配置一眼就更好读，而 Nginx 给你更显式的控制。

性能与内存：审慎地解读基准测试

已发布的测试大体指向同一个方向：Nginx 通常占用更少的内存，在原始吞吐量上也常常领先，但这份优势的大小在很大程度上取决于环境。

In 一次第三方四核虚拟机测试中，Nginx 达到约每秒 48,000 个请求，而 Caddy 约为 42,000。同一测试报告的 HTTPS p99 延迟，Nginx 为 2.1 ms，Caddy 为 2.4 ms。请把这些当作来自单一配置的结果，而非普遍适用的性能差距。

对比表中的内存区间来自一次 独立的 VPS 测试。另一项 在 50,000 个并发连接下的合成测试 报告 Nginx 为 145 MB、Caddy 为 520 MB，但该测试使用了截然不同的硬件和工作负载条件。其绝对数值不应与上面的 VPS 数字直接对比。

可靠的结论要窄得多：Nginx 通常内存占用更小，在高吞吐或高并发工作负载下往往领先。对于一台普通的中小型 VPS 反向代理，两者通常都足够快，因此运维上的简单往往才是更有用的决定因素。

本节要点： 根据运维来选择，除非你的服务器受内存约束，或你自己的负载测试表明代理吞吐量是瓶颈。

通配符证书的坑（Caddy 并非总是零配置）

Caddy 可以自动化通配符证书，但不能用它默认的 HTTP-01 或 TLS-ALPN-01 质询。一张针对 *.example.com 的证书需要 DNS-01 验证，这是 Let's Encrypt 对通配符证书的强制要求。这意味着需要一个 DNS 提供商插件（通过 xcaddy 编入你的 Caddy 二进制文件）外加一个用于你 DNS 主机的 API 令牌，并在 tls 块中配置。这可不是 Caddy 所宣传的“敲一行然后走人”的那种故事。

这会坑到那些把众多服务放在自己掌控的真实域名之下的家庭实验室用户，比如 *.home.example.com，并以为通配符签发会像 app.example.com那样自动。对于像 *.homelab.internal这样纯内部的名称，应把它当作本地/内部 PKI 的范畴，而不是公开的 Let's Encrypt 通配符。说得精确些：Caddy 处理通配符没问题，只是它不用默认质询来处理，而且这套配置比单域名的情形要更进一步。Nginx 在这一点上处境相同，因为 DNS-01 的要求来自 Let's Encrypt，而不是服务器。

如果你想要一个 GUI：Nginx Proxy Manager（简短的题外话）

Nginx Proxy Manager 与上面两个工具是完全不同的东西，值得用一段来讲，因为这个名字常让人混淆。NPM 是套在 Nginx 之上的 GUI 封装：它通过 port 81 上的 Web 界面管理反向代理规则和 Let's Encrypt 证书。它不是 Nginx 核心，配置方式也和 Nginx 核心不同。

这个权衡就是常见的“点击 vs 配置文件”之争。NPM 是那个省事的按钮，直到你偏离顺遂之路。它的配置通过一个应用数据库来管理，而不是一份手工编辑的单一配置文件。 默认的 Docker 部署使用 SQLite，而 MySQL/MariaDB 和 PostgreSQL 是受支持的外部数据库选项。这一差异也影响可移植性：一套 Caddy 配置往往只需复制一份 单一的 Caddyfile就能迁移，而一套 Nginx Proxy Manager 部署则需要保留它的 应用数据和数据库 。如果你确实更喜欢点击而非编辑，且你的部署保持简单，那 NPM 是个不错的选择。但对于基础设施即代码的工作流，它就是错误的选择。

从 Nginx 迁移到 Caddy（哪些能对应过去、哪些不能）

如果你已经在用 Nginx 并在权衡是否迁移，先把对自动化的期望降下来：确实有一个 Caddy 的 NGINX 配置适配器，但它并不完整，不应被当作可靠的一步到位迁移路径。从 Nginx 到 Caddy 的迁移大多是手动重写，而其中大部分内容都会变得更短。

哪些内容能对应过去并变得更简单，依据 Caddy 社区的转换指南:

• 对于 HTTP 上游， reverse_proxy 会把传入的 Host 头透传过去，并 默认设置标准的 X-Forwarded-* 头，因此大部分那些 proxy_set_header 行都会消失。
• PHP 从一个带有 try_files 加 fastcgi_pass 外加一堆参数的 location 块，收缩成单个 php_fastcgi 指令。
• 在 Caddy v2 中，WebSocket 的处理是自动的。如果某个教程让你添加一个单独的 websocket 指令，那是 Caddy v1 的遗留产物。忽略它。

哪些内容不能自动对应过去：任何绑定于某个 Caddy 没有的特定 Nginx 模块的东西、需要你重新思考而非照搬的复杂 rewrite 和 location 逻辑，以及通配符证书配置——它们会把你重新带回上一节的 DNS 质询配置。为这些模块和重写留出工时；其余部分通常在行数上是净减少的。

你该装哪一个？（结论）

你已经看过了配置、数字、通配符的坑以及迁移成本，那么结论就在这里。如果你是独立开发者或小团队、这是一次全新的 VPS 部署、你想要“一次配置、无需操心”的 TLS、你在跑带简单路由的 Docker，或者你只是想要一份能装进肌肉记忆的配置，那就装 Caddy。这适用于读到这里的大多数人。

如果你需要细粒度控制或它成熟生态中的某个特定模块、你在从一台受内存约束的服务器上榨取性能、你在做高并发的静态文件服务，或者你的团队已经拥有深厚的 Nginx 专业积累和一堆能用的配置，那就装 Nginx。这些都是扎实的理由，如果其中之一正是你的情况，那 Nginx 就是正确的选择。这并不是那种“更老的工具就是错的工具”的情形。

无论你最终选哪一个，下一步都是把它装到机器上。两者 Caddy 和 Nginx 都可以在我们的应用市场中一键部署，因此你可以跳过安装工作，直接上手 Caddyfile 或服务块。对于低流量的单站点部署，1 GB VPS 是一个合理的起点，但要按代理背后的应用和流量来给服务器选配，而不是只按代理本身。如果你把 Caddy 用作自托管服务的前门，它可以置于一套 Prometheus 和 Grafana 监控栈 或一套 Uptime Kuma 部署 之前，而无需单独的 TLS 工具。

本节要点： 选 Caddy，除非你有某个明确指向 Nginx 的具体理由。

常见问题