介绍

Caddy 是Go语言编写的开源现代化Web服务器/反向代理平台，核心标签：默认HTTPS、模块化架构、原生API动态配置、单静态二进制，由 Matt Holt 发起，现在归属 HID Global 旗下 ZeroSSL，源码 Apache‑2.0 协议，项目名称 Caddy 属于注册商标。它不只是HTTP服务器，本质是一套配置管理平台，HTTP、TLS都是可插拔的应用模块。

发展简史

1. Caddy v1（2015）：初代，首次提出自动HTTPS概念，MIT协议，Caddyfile配置诞生，收获大量开发者喜爱。
2. Caddy v2（2020‑05，完全重写）：架构彻底重构，内核改为JSON原生配置，真正模块化，开放配置适配器体系，支持HTTP/3，是现在主流版本，源码Apache‑2.0，编译二进制分发有商业条款约束。

   核心理念转变：v1侧重简单；v2追求可编程、大规模集群、动态配置。

整体架构设计

整体三层结构：命令引导层 → Caddy核心库 → 模块（所有业务能力全部由模块实现）。

1. 命令层：仅负责进程启动、引导核心，尽量不做业务配置，模块可以扩展子命令。
2. 核心库：只做配置管理，负责加载、热切换、停止配置，为所有模块提供公共工具、类型，本身不处理HTTP、TLS流量。配置变更完全热生效，不需要重启进程，支持RESTful JSON API远程下发配置。
3. 模块系统（最重要）
   • 所有功能都是模块：HTTP服务、TLS证书管理、反向代理、静态文件服务、日志、模板均为模块，没有写死在内核。
   • 分为标准内置模块与第三方扩展模块；模块之间可以互相调用。
   • 原生配置格式为JSON；Caddyfile只是内置的配置适配器，会被翻译成JSON交给内核执行；还支持YAML、TOML，甚至可以做Nginx配置的兼容转换适配器。

核心内置模块

• caddyhttp：HTTP应用模块，实现路由链、请求处理流水线，整个请求处理是一组有序Handler链式调用。
• caddytls：TLS/PKI模块，整套证书生命周期管理（申请、验证、存储、续期、OCSP装订、本地私有CA、按需TLS），是Caddy的王牌模块。
• reverse_proxy：反向代理模块，支持多种负载均衡策略、后端健康检查、熔断，后端不限于HTTP协议，可自定义传输层。
• file_server：静态文件服务模块。

核心能力

1. Automatic HTTPS（自动HTTPS，Caddy标志性能力）

内置完整 ACME客户端，默认行为就是HTTPS，区别于Nginx/Apache需要外部Certbot脚本、定时任务维护证书。

• 公网域名：自动对接 Let’s Encrypt / ZeroSSL，自动完成域名所有权校验（HTTP‑01、TLS‑ALPN‑01），后台自动续期，自动把80端口HTTP请求301重定向HTTPS。
• 内网/localhost/IP地址：内置私有根CA，自动生成自签证书；可把根证书导入系统信任库。
• On‑Demand TLS（按需TLS）独有特性：握手时动态申请证书，适合SaaS平台托管海量客户域名，无需提前预知全部域名，支持数万规模证书管理，专为大规模多站点场景设计。
• 证书存储、集群多实例证书同步、规避CA限流全部内置处理，不需要外部脚本。

注意：自动HTTPS是一套模块逻辑，可以按需关闭，并非强制开启。

2. 协议栈原生支持

默认完整支持 HTTP/1.1、HTTP/2、HTTP/3(QUIC)，HTTP/3基于UDP，UDP不通会自动降级，全部内置，无需额外编译模块。TLS默认启用TLS1.3，密码套件默认遵循现代安全规范。

3. 反向代理能力

Caddy的反向代理是高度可编程的：

• 多种负载算法：轮询、最少连接、IP哈希等；后端健康检查、故障熔断。
• 请求、响应完整修改：header增删、重写、重定向。
• 后端传输层可替换，代理后端可以不是HTTP服务。
• 支持动态上游列表，运行时可以变更后端节点，不需要重启。

4. 请求处理链与模板

HTTP请求经过一串Handler链式处理，可自由编排顺序：静态文件、代理、重定向、压缩（gzip/zstd）、鉴权、模板渲染。
内置模板引擎：可以对响应执行模板逻辑，支持变量、条件、Markdown渲染，静态页面也可以加入动态逻辑。

5. 二进制与跨平台特性

Go编译为静态单文件二进制，不依赖系统libc等外部库，Windows/Linux/macOS、arm等多架构直接运行，容器部署非常友好；依靠Go内存安全，规避C语言服务器常见内存溢出类漏洞。

6. 配置体系两套范式

1. JSON（原生底层）：API调用、集群动态管理首选，表达能力最强，适合程序驱动。
2. Caddyfile（高层适配语法）：人类手写，语法极简，没有复杂分号，可读性远高于Nginx配置；只是语法糖，内核收到的依然是JSON。

   适配器机制：输入任意格式，转换器输出JSON给Caddy内核执行，理论上可以用数据库做配置源。

Caddy vs Nginx

性能：Nginx在极高QPS纯静态场景仍有优势；Caddy足够绝大多数中小、中大型业务生产，证书管理、运维复杂度显著更低。

使用场景

适合场景

1. 需要大量HTTPS站点，不想维护证书脚本、定时任务；
2. SaaS多租户，大量动态域名，需要On‑Demand TLS；
3. 云原生、容器、单二进制部署；
4. 需要程序API动态控制反向代理配置；
5. 中小型网站、内部服务网关、开发环境。

不太适合场景

1. 追求极致极致吞吐的超大规模纯静态CDN节点；
2. 团队已有重度Nginx运维沉淀，大量复杂Nginx自定义模块。

局限与权衡

1. 第三方扩展需要重新编译二进制，不像Nginx可以加载动态so；
2. HTTP/3依赖UDP网络环境，部分IDC/防火墙会干扰UDP；
3. 自动HTTPS对公网环境有前置条件（端口可达、域名解析正确）；内网场景需要调整TLS策略；
4. 社区生态体量小于Nginx。

原文出处：/show_1GW3omNX7VBr.html