Caddy：默认自动 HTTPS 的可扩展 HTTP/1-3 服务器
一个给团队托管 HTTP/1-3 站点的 Go 服务器，默认办好 HTTPS，配置还能用 API 在线改。
GitHub caddyserver/caddy 更新 2026-10-06 分支 master 星标 77.1K 分叉 5.1K
Go HTTP/1.1-3 自动 HTTPS JSON API 跨平台

🧭 决策指南

为什么现在热： 无法从材料判断

适合，如果你

  • 你要部署支持 HTTP/1.1、HTTP/2 和 HTTP/3 的 HTTPS Web 服务器
    README 的 Features 章节明确列出三种协议均默认支持，并说明 Caddy 使用 TLS by default
  • 你希望用 Caddyfile 或 JSON API 管理站点，而不是只依赖命令行参数
    README 的 Features 和 Overview 章节分别列出 Caddyfile、JSON API，并称 API 是主要配置方式
  • 你需要公共域名证书或内部名称/IP 的本地 CA 管理
    README 的 Features 章节列出 ZeroSSL、Let's Encrypt 和 fully-managed local CA
  • 你要把 YAML、TOML 或 NGINX 配置转换为 Caddy 的 JSON
    README 的 Overview 章节明确列出 config adapters 以及 YAML、TOML、NGINX config

不适合，如果你

  • 你的发布流程必须从源码构建，但构建环境不能提供 Go 1.26.0 或更新版本
    README 的 Build from source 章节将 Go 1.26.0 or newer 列为要求
  • 你需要开发构建自动带有完整版本信息
    README 的 Build from source / For development 章节明确说明这些步骤不会嵌入 proper version information
  • 你的团队不准备理解 Caddy 的 JSON 配置结构，却要使用其深层模块配置能力
    README 的 Overview 章节称要发挥该设计能力，需要了解 config document 的结构

前置条件

  • 源码构建要求："Go 1.26.0 or newer"
  • 开发构建流程包含："git clone https://github.com/caddyserver/caddy.git"
  • 低端口场景在 Linux 上可使用："sudo setcap cap_net_bind_service=+ep ./caddy"
  • 项目提供跨平台 GitHub Releases 可执行文件，README 称其为 "The simplest, cross-platform way to get started"

第一步命令（README 原文）

$ git clone "https://github.com/caddyserver/caddy.git"

要注意

  • 绑定 80/443 等低端口时，Linux 可能需要 setcap 或提升权限
    README 的 Build from source 章节说明 Caddy 可能绑定 low ports，并给出 setcap 命令
  • 使用 go run 时需要配合 setcap.sh 处理低端口权限
    README 的 For development 章节给出 go run -exec ./setcap.sh main.go
  • 开发构建与正式版本的版本信息行为不同
    README 明确警告开发步骤不会嵌入 proper version information
  • README 要求完成 Getting Started 后继续阅读文档理解软件工作方式
    README 的 Quick start 章节要求完成 quick-start tutorial 后阅读更多文档

替代方案

  • NGINX：如果团队已有成熟的 NGINX 配置、模块和运维流程，NGINX 可能比引入 Caddyfile、JSON API 和 Caddy 模块体系更顺手
    通用领域知识

材料未说明

  • 材料没有说明 v2.11.7 对应的完整变更内容、升级兼容性和弃用项
  • 材料没有给出 HTTP/1.1、HTTP/2、HTTP/3 在具体硬件上的 CPU、内存和吞吐数据
  • 材料没有说明 ZeroSSL、Let's Encrypt 与本地 CA 在企业代理、离线环境或证书续期失败时的具体行为
  • 材料没有列出可用插件清单、插件版本兼容矩阵和自定义模块的发布流程
  • 材料没有说明多实例集群协调使用的存储、网络条件和一致性机制
  • 材料没有提供 Windows、macOS、Linux 各平台的安装包格式与服务管理集成细节

💡 深度解析

6
适合 我的客户端同时包含 HTTP/1.1、HTTP/2 和 HTTP/3，部署环境要求使用单一 Go 二进制且没有外部依赖；Caddy 能否作为统一入口？
适合读者： 需要在 HTTP/1.1、HTTP/2 和 HTTP/3 之间提供统一入口的网络工程师，同时希望保持单一 Go 二进制部署

适合，README 明确列出三种 HTTP 协议默认支持，并强调 Go 实现和无外部依赖部署。

  • Features 写明 HTTP/1.1、HTTP/2 和 HTTP/3 all supported by default，覆盖问题中的协议组合。
  • README 的描述是 Fast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS，项目主语言数据为 Go。
  • Features 还写明 Runs anywhere with no external dependencies，not even libc；这与单一可执行文件、跨平台部署约束一致。
  • Caddy 还提供 TLS by default、反向代理和静态文件服务能力，可作为统一 Web 入口而非只处理某一种协议。

README 没有给出不同协议下的性能、内核要求、QUIC 网络条件或硬件资源数据，因此不能据此推断具体吞吐量。

  • 项目描述：Fast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS
  • Features：HTTP/1.1, HTTP/2, and HTTP/3 all supported by default
  • Features：Runs anywhere with no external dependencies (not even libc)
  • 项目数据：main_language 为 Go
材料未说明：README 未提供 HTTP/1.1、HTTP/2、HTTP/3 的性能对比或资源消耗数据；README 未说明目标系统的 QUIC/UDP 网络条件、内核要求和硬件容量
适合 我们只有一个公开域名和一个上游应用，希望用单个跨平台二进制同时完成 HTTPS、反向代理，并避免额外的 libc 运行时依赖，Caddy 适合吗？
适合读者： 负责一个公开域名网站、希望用单个跨平台二进制完成 HTTPS 和反向代理部署的小型团队 DevOps 工程师

适合，因为 README 明确把自动 HTTPS、HTTP 服务和可跨平台运行的单一程序作为主要能力。

  • Caddy 默认启用 Automatic HTTPS，可使用 ZeroSSL 或 Let’s Encrypt 为 public names 申请证书并自动续期。
  • README 的 Features 同时列出反向代理能力；因此它可以承担公网入口和上游转发，而不必再组合独立 TLS 终止器。
  • 项目支持 HTTP/1.1、HTTP/2 和 HTTP/3，并声明 Runs anywhere、no external dependencies，甚至不依赖 libc。

前提是域名需要满足 ACME 验证条件；README 没有说明你的上游框架、流量规模或现有端口占用情况。

  • Features：Automatic HTTPS by default；ZeroSSL and Let's Encrypt for public names
  • Features：HTTP/1.1, HTTP/2, and HTTP/3 all supported by default
  • Features：Runs anywhere with no external dependencies (not even libc)
  • 项目数据：main_language 为 Go；description 为 multi-platform HTTP/1-2-3 web server with automatic HTTPS
材料未说明：README 未说明上游应用使用的框架、监听地址、WebSocket 或超时要求；README 未说明目标环境是否开放 ACME 所需的网络端口
适合 我已经使用 Go 1.26.0+，想把认证、存储或日志能力做成 Caddy 模块，并让它获得 JSON 文档、API 配置变更和统一生命周期管理；这个项目适合做扩展平台吗？
适合读者： 使用 Go 1.26.0+ 开发自定义认证或存储插件的工程师，希望把模块集成到 Caddy 的 HTTP/TLS 运行时

适合，Caddy 的 README 明确把自己定位为运行 Go 应用模块的平台，而不是只能配置固定功能的 Web 服务器。

  • Overview 说明 Caddy apps 是以 Caddy modules 实现的 Go programs，标准发行版包含 tls 和 http 两个 app。
  • README 指出模块可获得 automated documentation、通过 API 的 graceful on-line config changes，以及与其他 Caddy apps 的统一能力。
  • Features 将 modular architecture 和 powerful plugin system 列为核心特性；项目构建要求是 Go 1.26.0 or newer。

这与认证、存储、日志等扩展方向直接匹配。不过 README 没有说明你的模块接口版本、插件分发方式、兼容性承诺或测试矩阵，不能据此确认具体插件代码无需适配。

  • Build from source：Go 1.26.0 or newer
  • Overview：Caddy "apps" are just Go programs that are implemented as Caddy modules
  • Overview：apps instantly benefit from automated documentation, graceful on-line config changes via API, and unification with other Caddy apps
  • Features：Highly extensible modular architecture；powerful plugin system
材料未说明：README 未说明目标模块接口的稳定性、版本兼容策略和测试要求；README 未说明第三方插件的构建、签名、发布和安全审计流程
适合 我需要把入口配置集中成一个文档，并通过 API 在线修改 HTTP 处理器和 TLS 握手相关配置，避免重启 Caddy；这个运行时模型适合吗？
适合读者： 维护线上入口的 DevOps 工程师，要求通过 API 在不中断服务的情况下切换 HTTP/TLS 路由配置

适合，README 直接描述了集中式配置模型和 graceful online config changes via API。

  • Overview 表示几乎所有 Caddy 配置都收敛在 single config document，而不是分散在 CLI flags、环境变量和配置文件中，有利于控制面统一生成和审查。
  • README 将 JSON 作为 native config language，并把 JSON API 作为动态配置入口；Caddyfile、YAML、TOML 和 NGINX config 可通过 adapters 转成 JSON。
  • 同一节说明 API 变更作用于实际运行中的 HTTP handlers、TLS handshakes 和 storage medium，并明确支持 graceful on-line config changes。

但 README 没说明 API 的鉴权、配置校验失败后的行为、并发更新冲突处理或回滚语义，因此它支持在线变更这一决策，却不能替你确定生产控制面设计。

  • Overview：Nearly all of Caddy's configuration is contained in a single config document
  • Overview：JSON is Caddy's native config language；The primary way to configure Caddy is through its API
  • Overview：graceful on-line config changes via API
  • Overview：actual values ... power everything from HTTP handlers and TLS handshakes to your storage medium
材料未说明：README 未说明 JSON API 的认证、授权、TLS 保护和暴露边界；README 未说明配置校验失败、并发更新冲突及在线变更回滚的精确语义
适合 我的服务只使用内部名称和 IP，没有可用于公共 ACME 验证的域名；我仍想让 Caddy 自动管理内部 HTTPS，README 中的本地 CA 能满足这个约束吗？
适合读者： 负责内网开发环境的工程师，需要为内部名称和 IP 提供 HTTPS，同时不能依赖公共域名证书签发

适合内部环境，但它使用的是托管本地 CA，而不是公共证书机构签发的证书。

  • Features 明确列出 Fully-managed local CA for internal names & IPs，直接覆盖无公共域名、仅有内网名称或 IP 的场景。
  • 同一节把 ZeroSSL 和 Let’s Encrypt 限定为 public names，说明公共 ACME 证书与内部名称/IP 是不同路径。
  • Caddy 的定位是 TLS by default，并且自动 HTTPS 属于默认能力，因此内部 HTTPS 不需要另行拼装独立证书服务。

不过 README 没有说明客户端如何安装或信任本地 CA 根证书，也没有说明跨主机分发、吊销、备份和多实例共享的具体流程；这些会决定它能否满足你的组织级信任要求。

  • Features：Fully-managed local CA for internal names & IPs
  • Features：ZeroSSL and Let's Encrypt for public names
  • 项目描述：Caddy is an extensible server platform that uses TLS by default
  • Features：Automatic HTTPS by default
材料未说明：README 未说明客户端信任本地 CA 根证书的安装和分发方式；README 未说明本地 CA 的吊销、备份、密钥保护和跨实例共享流程
视情况 我需要管理数十万站点，并让多个 Caddy 实例协调证书状态；同时希望通过 API 集中下发配置。README 提到的能力是否足以支持这个入口平台？
适合读者： 维护数十万站点的托管平台工程师，要求入口层支持集中配置、集群证书协调和大规模站点管理

视情况，README 给出了规模和控制面方向，但没有覆盖平台化运行所需的全部运维细节。

  • Features 声称 Caddy 已在生产环境管理 millions of TLS certificates，并 Scales to hundreds of thousands of sites。
  • Automatic HTTPS 支持与其他 Caddy instances in a cluster 协调，且提供 Multi-issuer fallback，适合多实例证书生命周期管理。
  • Overview 将 JSON API、动态配置和 graceful on-line config changes 明确列为能力；配置适配器还可把 Caddyfile、YAML、TOML 或 NGINX config 转成 JSON。

但 README 没说明控制面鉴权、租户隔离、共享存储实现、API 限流、发布回滚或每实例资源上限，因此不能仅凭 README 判定完整托管平台可直接落地。

  • Features：Scales to hundreds of thousands of sites as proven in production
  • Features：Production-ready after serving trillions of requests and managing millions of TLS certificates
  • Features：Can coordinate with other Caddy instances in a cluster；Multi-issuer fallback
  • Overview：graceful on-line config changes via API；Nearly all of Caddy's configuration is contained in a single config document
材料未说明：README 未说明多租户权限模型、API 鉴权和租户间配置隔离；README 未说明共享证书存储的具体后端、集群一致性机制和单实例容量边界；README 未说明大规模配置变更的发布、回滚与限流机制

✨ 核心亮点

  • 默认启用 HTTPS，支持 ZeroSSL 与 Let's Encrypt
  • 原生支持 HTTP/1.1、HTTP/2 和 HTTP/3
  • Caddyfile、JSON 与 JSON API 可协同配置
  • Go 模块化架构支持插件扩展且无外部依赖
  • README 称已处理数万亿请求和数百万 TLS 证书

🔧 工程化

  • Caddyfile 提供简易配置，JSON API 支持在线配置变更
  • JSON 是原生配置格式，适配器可转换 YAML、TOML 和 NGINX 配置
  • Automatic HTTPS 为公共域名申请证书并管理内部 CA
  • tls 和 http 两个 Caddy app 随标准发行版提供

⚠️ 风险

  • 低端口绑定可能需要 Linux setcap 或提升权限
  • 源码构建要求 Go 1.26.0 或更新版本
  • README 要求理解 JSON 配置结构才能驾驭完整能力
  • 开发构建不会嵌入 proper version information

👥 适合谁？

  • 需要 HTTP/1.1、HTTP/2、HTTP/3 的 Web 服务团队
  • 希望用 Caddyfile 或 JSON API 管理 TLS 的运维团队
  • 需要 Go 模块和插件系统扩展长期运行服务的开发者