(1) ~*, 表示不区分大小写的匹配。
(2) ~, 表示区分大小写的匹配。
对于非正则的匹配,即字符串匹配,有如下前缀:
(1) ^~, 表示匹配到字符串后,终止正则匹配。
(2) =, 表示精确匹配。
(3) @, 当然,这个也算不上字符串匹配。如果可以,你也可以将其理解成是正则匹配。它是一个命名标记,这种 location 不会用于正常的请求,它们通常只用于处理内部的重定向。
在匹配过程中,Nginx 将首先匹配字符串,然后匹配正则表达式。匹配到第一个正则表达式后,会停止搜索。如果匹配到正则表达式,则使用正则表达式的搜索结果,如果没有匹配到正则表达式,则使用字符串的搜索结果。
上面这段话的意思是说,有一个字符串和正则表达式均能匹配上,那么会使用正则表达式的搜索结果。这里,我们可以使用前缀"^~" 来禁止匹配到字符串后,继续检查正则表达式。匹配到 URI 后,将停止搜索。
使用前缀 "=" 可以进行精确的 URI 匹配,如果找到匹配的 URI,则停止搜索。"location = /" 只能匹配到 "/",而 "/test.html" 则不能被匹配。
正则表达式的匹配,按照它们在配置文件中的顺序进行,写在前面的优先。
另外,前缀 "@" 是一个命名标记,这种 location 不会用于正常的请求,它们通常只用于处理内部的重定向(例如:error_page, try_files)。
最后总结一下匹配的过程:
(1) 前缀 "=" 先进行匹配,如果找到了,终止搜索。
(2) 对所有其它 location 进行非正则的匹配,找到最精确匹配(对于 /blog/admin/ 这个 URI, location /blog 要比 location / 长,因此 location /blog 要比 location / 要精确)的那个。如果找到的这个是带"^~" 前缀的,则终止搜索并直接返回找到的这个,否则开始正则查找。会不会出现所有的非正则匹配都无法匹配到 URI 呢,当然,你若不定义一个 location /,这种情况的确会发生,没关系啊,它会进行正则查找的。
(3) 正则查找,按照我们配置文件中配置的 location 顺序进行查找。
(4) 如果正则查找匹配成功,则使用此正则匹配的 location,否则,使用第二步查找的结果。如果『否则』发生了,同时,第二步中的粗体字部分的假设的情况也发生了,怎么办?404 会等着你的。
例子:
location = / {
# 只匹配 / 查询。
[ configuration A ]
}
location / {
# 匹配任何查询,因为所有请求都已 / 开头。但是正则表达式规则和长的块规则将被优先和查询匹配。
[ configuration B ]
}
location ^~ /images/ {
# 匹配任何已 /images/ 开头的任何查询并且停止搜索。任何正则表达式将不会被测试。
[ configuration C ]
}
location ~* \.(gif|jpg|jpeg)$ {
# 匹配任何已 gif、jpg 或 jpeg 结尾的请求。然而所有 /images/ 目录的请求将使用 Configuration C。
[ configuration D ]
}
例子请求:
1, / -> 精确匹配到第1个location,匹配停止,使用configuration A
2,/some/other/url -> 首先前缀部分字符串匹配到了第2个location,然后进行正则匹配,显然没有匹配上,则使用第2个location的配置configurationB
3,/images /1.jpg -> 首先前缀部分字符串匹配到了第2个location,但是接着对第3个location也前缀匹配上了,而且这时已经是配置文件里面对这个url的最大字符串匹配了,并且location带有 "^~" 前缀,则不再进行正则匹配,最终使用configuration C
4,/some/other/path/to/1.jpg -> 首先前缀部分同样字符串匹配到了第2个location,然后进行正则匹配,这时正则匹配成功,则使用congifuration D
注意:按任意顺序定义这4个配置结果将仍然一样。