Caddyfile编辑说明

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

你可以忽略匹配器表示来匹配所有请求。举个例子，*并不需要给出如果下一个参数看着不像是一个路径匹配器。