配置

JSON 配置

Caddy 的原生配置语言，能力完整、可编程、可导出。

JSON 是 Caddy 的原生配置语言。它表达能力完整、容易由程序生成、支持配置遍历，也兼容所有 API 端点。Caddyfile 只是它的一种更顺手的外衣。

顶层结构

caddy.json

{
	"admin": {},
	"logging": {},
	"storage": {},
	"apps": {
		"http": {},
		"tls": {},
		"pki": {}
	}
}

admin 配置管理端点的监听地址与权限
logging 配置日志的输出、格式与级别
storage 选择证书与资产的存储介质
apps 是真正的应用，每一个都是一组长期运行的模块

标准发行版自带 tls 与 http 两个应用，其余的随插件进入配置。

HTTP 应用

HTTP 应用按「服务器 / 路由 / 匹配器 / 处理器」组织。一份能跑的完整示例如下：

最小可用配置

{
	"apps": {
		"http": {
			"servers": {
				"srv0": {
					"listen": [":443"],
					"routes": [
						{
							"match": [{ "host": ["example.com"] }],
							"handle": [
								{ "handler": "vars", "root": "/var/www" },
								{ "handler": "file_server" }
							],
							"terminal": true
						}
					],
					"automatic_https": {
						"disable_redirects": false
					}
				}
			}
		},
		"tls": {
			"automation": {
				"policies": [{ "subjects": ["example.com"] }]
			}
		}
	}
}

servers 的每个键是一台服务器，listen 是监听地址数组
routes 按顺序求值，match 为空表示匹配所有请求
handle 是一组处理器，按序执行；terminal表示匹配后不再向后走
证书的自动化策略独立在 tls 应用里，通过 subjects 关联域名

处理器与匹配器都是模块

每个处理器对象里的 handler 字段就是一个模块名，例如file_server、reverse_proxy、static_response。匹配器同理，写在match 数组里：

组合匹配器

{
	"match": [
		{
			"host": ["example.com"],
			"path": ["/api/*"],
			"method": ["POST", "PUT"]
		}
	]
}

多个匹配器对象之间是与的关系，对象内部各字段之间也是与的关系。

文档是自动生成的

JSON 配置的参考文档由模块的元数据自动生成，因此它与实际行为保持一致。每个模块的文档页都能从模块索引一路点进去，字段含义、默认值、与其他模块的关系都在那里。