Caddy介绍-马育民老师

# 介绍

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://www.malaoshi.top/show_1GW3orXUqb1m.html "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|Caddy|
|---|---|---|
|开发语言|C，事件驱动worker进程模型|Go，Goroutine协程池|
|HTTPS证书|完全依赖外部工具（Certbot+crontab）|内核内置完整证书生命周期管理|
|配置变更|reload重载，传统文件驱动|支持文件 + **HTTP API动态热更新**|
|扩展方式|编译模块/动态so模块|编译时嵌入Go模块，无运行时加载so|
|默认安全|HTTP为主，HTTPS需要手动配置|**默认优先HTTPS**|
|配置范式|原生复杂配置语法|底层JSON，Caddyfile为适配层|
|定位|极致性能静态代理，2004年解决C10K|现代安全优先，降低HTTPS运维负担|

**性能：**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