location [=|~|~*|^~] /uri/ { … }
构成:
路由匹配规则,正则匹配,正则表达式
2)location区分普通匹配和正则匹配
用前缀“~”和“~*”修饰的为正则匹配
除上面修饰的前缀(“=”和 “^~”,或没有前缀修饰)都为普通匹配
^~ 前缀表示uri以某个常规字符串开头,可以理解为url的普通匹配
location作用于server模块,且支持多个location模块
server {
.........
location /p {
root html/p;
index index.html index.htm;
}
location = /50x.html {
root html;
}
location / {
root html/server1;
index index.html index.htm;
}
}
在多个location情况下,是按照什么原则进行匹配的呢?
普通匹配:优先原则---->最大前缀匹配原则; 顺序无关
如:
请求url为:/prefix/mid/t.html
此请求匹配的是 规则B,是以最大的匹配原则进行的,跟顺序无关
正则匹配:为顺序匹配,优先原则:谁在前面 就匹配谁;顺序相关
如:
请求http://localhost/1.png,匹配的是规则C,因为规则C在前面,即叫做顺序匹配
如果location有普通匹配也有正则匹配,那匹配的原则为:
匹配模式及顺序:带前缀普通匹配最优先,=前缀优先级最高
正则匹配
不带前缀匹配
首先匹配 =,其次匹配^~, 其次是按文件中顺序的正则匹配,不带前缀普通匹配,最后是交给 / 通用匹配。
当有匹配成功时候,停止匹配,按当前匹配规则处理请求。
例子,有如下匹配规则:
那么产生的效果如下:
4)在实际场景中,通常至少有三个匹配规则定义,如下:
#直接匹配网站根,通过域名访问网站首页比较频繁,使用这个会加速处理。
#这里是直接转发给后端应用服务器了,也可以是一个静态首页
# 第一个必选规则
第二个必选规则是处理静态文件请求,这是nginx作为http服务器的强项
# 有两种配置模式,目录匹配或后缀匹配,任选其一或搭配使用
#第三个规则就是通用规则,用来转发动态请求到后端应用服务器
#非静态文件请求就默认是动态请求,自己根据实际把握
#毕竟目前的一些框架的流行,带.php,.jsp后缀的情况很少了