本文我们来给大家详细介绍下Nginx中的核心配置文件中的Location匹配规则。
  location会尝试根据用户请求中的URI来匹配上面的/uri表达式，如果可以匹配，就选择location{}块中的配置来处理用户请求。当然，匹配方式是多样的，
下面介绍location的匹配规则。
语法：

location [=|~|~*] /uri/ { 
… 
}

  

 

  
1
  
2
  
3
 

~ #波浪线表示执行一个正则匹配，区分大小写
~* #表示执行一个正则匹配，不区分大小写
= #进行普通字符精确匹配

URI匹配模式

location的指令分为两种匹配模式
1.普通字符串匹配： 以=开头或者没有带正则引导符号（~）规则
2.正则匹配：以（_{）开头或者（}*）开头的表示正则匹配

普通匹配模式

location / {
    root   html;
    index  index.html index.htm;
}
location /demo {
    root   html;
    index  demo.html;
}

  

 

  
1
  
2
  
3
  
4
  
5
  
6
  
7
  
8
 

1.配置两个location， 第一个是匹配根路径”/”， 另一个是匹配 “/demo”路径
2.在html目录下创建一个demo目录， 因为/demo相当于是一个虚拟主机目录，最终访问的地址会变成/demo/demo.html
3.重新加载配置文件’./nginx -s reload’
4.通过在浏览器中输入http://localhost/ 以及http://localhost/demo 可以看到我们访问到了对应的路径

匹配规则：
location不是严格匹配，而是一个“前缀匹配”过程，所以在上面那个案例中，两个location都能够匹配，但是普通匹配会遵循一个最长匹配规则，也就是上面的请求中，最终uri会匹配到长度最大location。也就是/demo

精准匹配模式

  在普通匹配模式中，还可以细分出一种叫精准匹配模式，也就是通过等于号直接来匹配的

location =/demo {
    root  html; 
    index gp.html;
}
location /demo {
   root   html;
   index  demo.html;
}

  

 

  
1
  
2
  
3
  
4
  
5
  
6
  
7
  
8
 

我们继续沿着上面的案例来添加一个基于 location =/demo的匹配规则，那么这个时候的匹配就是精准匹配。精准匹配和普通匹配的差异在哪里呢？以及匹配顺序是什么样的？
http://localhost/demo √
http://localhost/demo/demo.html √
http://localhost/demo/gp.html √ (精准匹配)
但是在此处并不能证明此处是精准匹配

#location =/demo {
 #   root  html; 
  #  index gp.html;
#}
location /demo {
   root   html;
   index  demo.html;
}

  

 

  
1
  
2
  
3
  
4
  
5
  
6
  
7
  
8
 

把精准匹配注释掉
http://localhost/demo √
http://localhost/demo/demo.html √
http://localhost/demo/gp.html √ (普通匹配)

location =/demo {
    root  html; 
    index gp.html;
}
#location /demo {
 #  root   html;
  # index  demo.html;
#}

  

 

  
1
  
2
  
3
  
4
  
5
  
6
  
7
  
8
 

我们把普通匹配注释掉发现：
http://localhost/demo ×
http://localhost/demo/demo.html √
http://localhost/demo/gp.html √
第一种方式访问不了。但这也证明不了精准匹配的优先级比普通匹配高，这时我们可以这样设置

location =/index.html {  # 精准匹配
    root  html/gp1;
    index index.html;
}
location /index.html {  # 普通匹配
    root html/gp2;
    index index.html;
}

  

 

  
1
  
2
  
3
  
4
  
5
  
6
  
7
  
8
 

然后我们再访问

访问到的是gp1目录中的，说明普通匹配没起作用。

正则匹配模式

  正则匹配在实际应用中也会用得比较多，比如接下来给大家演示一个基于正则匹配的案例

location ~* \.(jpg|png|css|js|gif)$ {
    root html/images;
}

  

 

  
1
  
2
  
3
 

然后我们在html目录下创建images文件夹，里面放入一张图片。Reload nginx服务后，访问

  正则匹配在三种匹配模式中的优先级是什么样的呢？前面我们讲了一般匹配，最终会选择最大前缀匹配。但是匹配后不会停止匹配，最大匹配只是一个临时结果，nginx还需要继续检查正则location。那么正则匹配规则是什么样的？按照正则location在配置文件中的物理顺序匹配。如果匹配到一条正则location，就不再考虑后面的规则

匹配的优先级

1. 首先看有没有精准匹配，如果有，则停止匹配过程
2. 判断普通命中，如果有多个命中，“记录”下最长的命中结果（记录但不结束）
3. 继续判断正则表达式，按配置里的正则表达式顺序为准，由上到下开始匹配，一旦匹配成功一个，立即返回结果并结束
   a) 普通命中，顺序无关，因为按照命中长短来确定
   b) 正则命中，顺序有关系，因为是从前往后命中

实际使用的建议

  所以实际使用中，至少有三个匹配规则定义
直接匹配网站根，通过域名访问网站首页比较频繁，使用这个会加速处理
这里是直接转发给后端应用服务器了，也可以是一个静态首页
第一个必选规则

location  =/ {
    proxy_pass http://tomcat:8080/index
}

  

 

  
1
  
2
  
3
 

第二个必选规则是处理静态文件请求，这是nginx作为http服务器的强项
有两种配置模式，目录匹配或后缀匹配,任选其一或搭配使用

location ^~ /static/ {
    root /webroot/static/;
}

  

 

  
1
  
2
  
3
 

location ~* \.(gif|jpg|jpeg|png|css|js|ico)$ {
    root /webroot/res/;
}

  

 

  
1
  
2
  
3
 

第三个规则就是通用规则，用来转发动态请求到后端应用服务器
非静态文件请求就默认是动态请求，自己根据实际把握

location / {
    proxy_pass http://tomcat:8080/
}

  

 

  
1
  
2
  
3
 

文章来源: dpb-bobokaoya-sm.blog.csdn.net，作者：波波烤鸭，版权归原作者所有，如需转载，请联系作者。

原文链接：dpb-bobokaoya-sm.blog.csdn.net/article/details/106232388