Caddyfile是一种对人类友好的Caddy配置格式。这是大多数人最喜欢的使用Caddy的方式,因为它易于编写、易于理解,对于大多数用例来说,表达能力也足够强。
以下是一个例子:
example.com
root * /var/www/wordpress
php_fastcgi unix//run/php/php-version-fpm.sock
file_server
这是一个真正的可以用于生产环境的Caddyfile。它可以用来部署Wordpress,还能实现HTTPS的自动部署。
概述
结构
Caddyfile的文件结构可以直观的表述为:

关键点:
- 全局选项块是可选择的但是必须放在文件的第一个位置上。
- 否则,Caddyfile的第一行总是服务器的地址
- 所有的指令和匹配都需要在站点块中。站点块不具有全局性和可继承性。
- 如果只有一个站点块,那么花括号
{}
是可选择的。
Caddyfile总是以站点地址(addresses)开始的。任何在地址之前的指令(directives)都会使解释器发生错误。
块
块是由一对花括号包裹形成的:
... {
...
}
- 左花括号
{
必须是行的末尾 - 右花括号
}
必须是行的开始位置
如果只有一个站点块的话,花括号和缩进是可选的。这样可以比较方便的定义单个站点,就像这样:
localhost
reverse_proxy /api/* localhost:9001
file_server
这等效于:
localhost {
reverse_proxy /api/* localhost:9001
file_server
}
如果你只有一个网站的话,是否使用花括号取决于你的个人喜好。
如果你想要配置多个站点在同一个Caddyfile中的话,你必须像这样使用花括号把他们分隔开来:
example1.com {
root * /www/example.com
file_server
}
example2.com {
reverse_proxy localhost:9000
}
如果一个请求匹配到多个块,那它会选择匹配地址最具体的那个块。请求不会影响到其他块。
指令
指令是一系列用来配置站点如何提供服务的关键词。举个例子,一个完整的文件服务的配置可能如下所示:
localhost
file_server
或者一个反向代理服务:
localhost
reverse_proxy localhost:9000
在这些例子中,file_server
和reverse_proxy
都是指令。指令是站点块中一行的第一个单词。
在第二个例子中,localhost:9000
是一个参数因为它出现在指令的后面。
每当Caddyfile改变时,指令都会根据特定的指令排序规则重新排序。
子指令可以出现在指令块中,就像这样:
localhost
reverse_proxy localhost:9000 localhost:9001 {
lb_policy first
}
在这里,lb_policy
是一个reverse_proxy
的子指令,用来设置负载均衡。
标记和引号
在解析前,Caddyfile会被拆解成一个标记序列(Tokens)。空格对于Caddyfile来说是非常重要的,因为标记序列就是根据空格分隔而产生的。
通常情况下一个指令需要一些参数。如果一个参数有空格,那么它会被拆解成两个不同的标记:
directive abc def
这会产生问题并引发意外。
如果abc def
整体作为单个参数的话,它应该被引号所括起来:
directive "abc def"
如果你想在参数中使用双引号,你可以使用转义符:
directive "\"abc def\""
在引号内的所有其他字符都按照字面意思处理,包括空格,制表符还有新的一行。
你也可以使用反引号来将标记括起来:
directive `"foo bar"`
当标记包含引号文字时,例如JSON文本,反引号字符串是很方便的。
地址
地址通常出现在一个站点块的最开始的位置。
一下是一些有效的地址的示例:
localhost
example.com
:443
http://example.com
localhost:8080
127.0.0.1
[::1]:2015
example.com/foo/*
*.example.com
http://
根据地址,Caddy可以隐形的知道访问方式,主机名,端口还有站点的路径。
如果你指定了主机名,只有匹配的主机名的请求才会被执行。也就是说,如果站点的地址是localhost
,那么Caddy就无法匹配请求至127.0.0.1
你可以使用通配符(*
),但是它只能匹配主机名中的一段。举个例子,*.example.com
能够匹配foo.example.com
但是却不能匹配foo.bar.example.com
,还有*
可以匹配localhost
但是不能匹配example.com
。
为了匹配所有的主机名,你可以省略地址中的主机名的部分。
如果有多个站点共享同一种定义,那么你可以就像这样将他们全部列起来:
localhost:8080, example.com, www.example.com
或者这样
localhost:8080,
example.com,
www.example.com
注意逗号代表的地址的延续。
每一个地址必须是不同的。你不能多次指定同一个地址。
匹配器
默认情况下,注入HTTP处理程序的指令适用于所有请求。‘
请求匹配器可以更根据既定的规则将请求分类。这个特性来自底层的JSON结构,这对怎样在Caddyfile中使用他们显得非常重要。通过匹配器你可以精确的指定某个命令适用于哪些请求。
对于一些支持匹配器的指令,在指令后的第一个参数就是匹配器的标识。以下是一些例子:
root * /var/www # matcher token: *
root /index.html /var/www # matcher token: /index.html
root @post /var/www # matcher token: @post
你可以忽略匹配器表示来匹配所有请求。举个例子,*
并不需要给出如果下一个参数看着不像是一个路径匹配器。