精确匹配 > 字符串匹配( 长 > 短 [ 注: ^~ 匹配则停止匹配 ]) > 正则匹配( 上 > 下 )
在nginx的location和配置中location的顺序没有太大关系。正location表达式的类型有关。相同类型的表达式,字符串长的会优先匹配。
优先级排列:
1)等号类型(=)的精确匹配优先级最高,精确匹配只能命中一个。一旦匹配成功,则不再查找其他匹配项。
2)^~类型表达式,即字符串匹配,使用匹配最长的最为匹配结果。一旦匹配成功,则不再查找其他匹配项。
3)正则表达式类型(~ ~*)的优先级次之。如果有多个location的正则能匹配的话,则使用正则表达式最长的那个。
4)常规字符串匹配类型。按前缀匹配。
特别注意:
字符串匹配优先搜索,但是只是记录下最长的匹配 (如果 ^~ 是最长的匹配,则会直接命中,停止搜索正则),然后继续搜索正则匹配,如果有正则匹配,则命中正则匹配,如果没有正则匹配,则命中最长的字符串匹配.
实例说明:
1)先来测试下区分大小写和不区分大小写的优先级.如下:
location ~
/5b
.txt {
return
501
}
location ~*
/5b
.txt {
return
504
}
测试结果为:
http:
//192
.168.1.80
/5b
.txt ------------501
http:
//192
.168.1.80
/5B
.txt ------------504
将顺序反下,将~*放前面
location ~*
/5b
.txt {
return
501
}
location ~
/5b
.txt {
return
504
}
测试结果为:
http:
//192
.168.1.80
/5b
.txt ------------501
http:
//192
.168.1.80
/5B
.txt ------------501
结论: 去分和不区分大小写的正则匹配优先级相同,以先后顺序来决定匹配哪一个.
2)再来比较=与~的优先级
location =
/5b
.txt {
return
502
}
location ~
/5b
.txt {
return
504
}
测试结果为:
http:
//192
.168.1.80
/5b
.txt -------------502
结论:=的优先级比~高
3)再来比较下 ^~ 与 ~的优先级
location ~
/5b
.txt {
return
502
}
location ^~
/5b
.txt {
return
504
}
测试结果为:
http:
//192
.168.1.80
/5b
.txt --------------504
结论:^~的优先级比~高
4)再测试 ^~ 与 = 的优先级
location ^~
/5b
.txt {
return
502
}
location =
/5b
.txt {
return
504
}
测试结果:
http:
//192
.168.1.80
/5b
.txt --------------504
结论:=的优先级比 ^~高
5)再来测试^~同级之间的优先级
location ^~ 5b.txt {
return
502
}
location ^~
/3a/
{
return
504
}
测试结果:
http:
//192
.168.1.80
/5b
.txt --------------504
结论 :^~优先匹配的是从根开始的匹配
6)再来看空格(即什么都不加)与~的优先级比较
location
/5b
.txt {
return
502
}
location ~
/5b
.txt {
return
504
}
测试结果为:
http:
//192
.168.1.80
/5b
.txt --------------504
结论:空格的优先级比~低
优先级排序为:
空格(即不加)
~与*~正则匹配的优先级按先后次序来决定的
^~同级之间的匹配是按照根目录顺序来的
------------------------------------------------------------------------------------------
再来看看下面的例子:
1)精确匹配,即“=”
location =
/images/test
.png {
echo
'config1'
;
}
location
/images/test
.png {
echo
'config2'
;
}
location \
/images
\
/test
\.png$ {
echo
'config3'
;
}
如果此时请求 http:
//127
.0.0.1
/images/test
.png 输出的内容是config1, 毋容置疑,精确匹配优先级最高!
2)精确匹配的特殊情况
location = / {
index index.html;
}
location / {
echo
'config2'
;
}
此时输入http:
//127
.0.0.1 输出的内容是config2, 怎么精确匹配的优先级不灵了呢?
是这样的,精确匹配还是起作用了,请求目录(非具体文件),nginx会将请求内部定向到index文件,
既此时真正的请求是http:
//127
.0.0.1
/index
.html, 这是config2则被命中!
所以精确匹配不要用来匹配/
3)字符串搜索与正则搜索
location
/images/test
.png {
echo
'config1'
;
}
location ^~
/images/
{
echo
'config2'
;
}
location ~ \
/images
\
/test
\.png$ {
echo
'config3'
;
}
location ~ \
/images
\/ {
echo
'config4'
;
}
如果此时请求http:
//127
.0.0.1
/images/test
.png 输出的内容是config3,正则命中。
(虽然config1为最长匹配的字符串,此时只做记录,后面还要搜索正则匹配,则config3正则匹配命中),
仔细观察可以发现config4也被匹配成功了,但是正则的匹配顺序是按照location的定义顺序匹配的,所以config3命中.
4)字符串匹配优先级的提升( ^~ )
location
/images/
{
echo
'config1'
;
}
location ^~
/images/test
.png {
echo
'config2'
;
}
location ~
/images/test
\.png$ {
echo
'config3'
;
}
location ~ \
/images
\/ {
echo
'config4'
;
}
如果此时请求 http:
//127
.0.0.1
/images/test
.png 输出的内容是config2, 首部匹配命中。
(因为字符串匹配是优先搜索的,此时发现config2 为最长的字符串匹配且为^~匹配方式,所以停止搜索正则,直接命中!)
所以这里的 ^~ 符号比较特殊,就是为了提高字符串匹配的优先级,优先于正则匹配.
------------------------------------------------------------------
/ 通用匹配,任何请求都会匹配到。
多个location配置的情况下,需要遵循:
首先匹配=
其次匹配^~
再其次按照配置文件的顺序进行正则匹配、
最后是交给/进行通用匹配
注意:当有匹配成功时,立刻停止匹配,按照当前匹配规则处理请求
看看下面匹配规则:
#规则A
location = / {
}
#规则B
location =
/login
{
}
#规则C
location ^~
/static/
{
}
#规则D
location ~ \.(gif|jpg|png|js|css)$ {
}
#规则E
location ~* \.png$ {
}
#规则F
location !~ \.xhtml$ {
}
#规则G
location !~* \.xhtml$ {
}
#规则H
location / {
}
那么产生的效果如下:
1)访问根目录/, 比如http:
//localhost/
将匹配规则A
2)访问 http:
//localhost/login
将匹配规则B,http:
//localhost/register
则匹配规则H
3)访问 http:
//localhost/static/a
.html 将匹配规则C
4)访问 http:
//localhost/a
.gif, http:
//localhost/b
.jpg 将匹配规则D和规则E,但是规则D顺序优先,规则E不起作用,而 http:
//localhost/static/c
.png 则优先匹配到规则C
5)访问 http:
//localhost/a
.PNG 则匹配规则E,而不会匹配规则D,因为规则E不区分大小写。
6)访问 http:
//localhost/a
.xhtml 不会匹配规则F和规则G,http:
//localhost/a
.XHTML不会匹配规则G,因为不区分大小写。规则F,规则G属于排除法,符合匹配规则但是不会匹配到,所以想想看实际应用中哪里会用到。
7)访问 http:
//localhost/category/id/1111
则最终匹配到规则H,因为以上规则都不匹配,这个时候应该是nginx转发请求给后端应用服务器,比如FastCGI(php),tomcat(jsp),nginx作为方向代理服务器存在。
注意:在实际使用中,至少清楚下面匹配规则
1)直接匹配网站根,通过域名访问网站首页比较频繁,使用这个会加速处理,官网如是说。
2)这里是直接转发给后端应用服务器了,也可以是一个静态首页
第一个必选规则:
location = / {
proxy_pass http:
//tomcat
:8080
/index
}
第二个必选规则是处理静态文件请求,这是nginx作为http服务器的强项
有两种配置模式,目录匹配或后缀匹配,任选其一或搭配使用
location ^~
/static/
{
root
/webroot/static/
;
}
location ~* \.(gif|jpg|jpeg|png|css|js|ico)$ {
root
/webroot/res/
;
}
第三个规则就是通用规则,用来转发动态请求到后端应用服务器
非静态文件请求就默认是动态请求,自己根据实际把握
毕竟目前的一些框架的流行,带.php,.jsp后缀的情况很少了
location / {
proxy_pass http:
//tomcat
:8080/
}