一、语法规则：

• = 开头表示精确匹配

• ^~ 开头表示uri以某个常规字符串开头，理解为匹配url路径即可(非正则)

• ~ 开头表示区分大小写的正则匹配

• ~* 开头表示不区分大小写的正则匹配

• !~和!~*分别为区分大小写不匹配及不区分大小写不匹配的正则

• / 通用匹配，任何请求都会匹配到

优先级：

• 等号类型（=）的优先级最高。一旦匹配成功，则不再查找其他location的匹配项

• ^~和通用匹配。使用前缀匹配，不支持正则表达式，如果有多个location匹配成功的话，不会终止匹配过程，会匹配表达式最长的那个(下方有例子)

• 如果上一步得到的最长的location为^~类型，则表示阻断正则表达式，不再匹配正则表达式

• 如果上一步得到的最长的location不是^~类型，继续匹配正则表达式，只要有一个正则成功，则使用这个正则的location，立即返回结果，并结束解析过程

二、验证：

1、精确匹配：

在conf.d文件夹下创建配置文件test.com.conf，内容如下：

上图中第一个和第二个location匹配条件一样，都是/test.html，但第二个为精准匹配到静态路径，因此第一个不会执行，会执行第二个，www.test.com为本地域名解析，access_log和error_lor可以单独为每个模块定义日志

通过域名和路径访问后的内容如下：

注意：路径/usr/share/nginx/test_html文件夹下需要有test.html才可以正常访问

上图中指定静态资源路径用的关键字root，还可以用alias，那么root和alias的区别是什么？

• 用root属性指定的值是要加入到最终路径中的，匹配条件会拼接到路径中

• 用alias属性指定的值不需要加入到最终路径中

如上图中所示，请求的条件为test.html，通过root指定的路径为/usr/share/nginx/test_html，因此在匹配的时候，这个路径下就必须要有test.html这个文件才可以，否则就会找不到而报错，如果用alias，那么通过浏览器进行请求的时候，alias也是指定到/usr/share/nginx/test_htm路径下，但是会匹配默认的index.html，而无须强制匹配test.html，但是此时就不能使用”=”来进行精确匹配，现在将root改为alias,如图：

注意：alias指定的路径结尾要加”/”

下面的配置文件采用roo指定路径，当通过域名请求http://www.test.com/html/的时候，将跳转到/usr/share/nginx/html/下的index.html页面，如图：

下面的配置文件采用alias指定路径，请求http://www.test.com/linshi/的时候，将跳转到/usr/share/nginx/test_html/index.html页面，如图：

2、通过^~方式实现匹配：

例如：下面配置文件有两条规则，分别匹配url以字母a开头，但是长度不同，首先将长的规则先注释掉，如图：

通过curl请求查看状态码，如图：

说明：当前只有一个规则开启，因此当匹配url以/a/开头的任何url时，都会返回状态码666

现在将第二条规则注释取消，打开规则，如图：

再次发起同样的请求，观察返回状态码，如图：

从上图可以看出，两条规则同时被匹配成功，但是第二条规则比较长，因此第二条规则优先被匹配，如果^~匹配成功了，那么表示阻断正则表达式，不再进行正则匹配

3、通过”~”方式实现匹配：

上图中的匹配规则都是通过”^~”方式来实现的，那么在匹配最长规则的时候又分为两种情况：

• 第一种：最长规则通过^~来实现匹配(上图中的最长规则就是通过^~实现)

• 第二种：最长的规则不是通过^~实现匹配，而是通过普通匹配来实现

当最长规则是通过普通匹配的时候，将会继续正则匹配， 只要有一个正则成功，则使用这个正则的location，停止继续匹配，返回结果

现在将第二条规则改为普通匹配，并添加一条正则匹配，如图：

再次执行同样的请求命令，得到的状态码如下：

说明：从上图可以看出请求/a/b/的时候，首先会到达第二条规则(最长规则)，由于第二条规则为普通匹配(不是^~匹配)，因此会继续去匹配正则，也就是第三条规则，因此最终返回状态码为888

4、通过"~*"方式实现匹配:

” ~* ” 表示不区分大小写的正则匹配

例如：通过url请求/a/b/或者/A/B/，查看返回状态码，如图：

请求结果如下：

从上图可以看出，无论匹配的是大写还是小写，都会返回对应状态码888

常用方法还有匹配图片后缀，并返回指定信息，如图：

5、”!~*” 和”!~” 不常用，再次不做介绍

6、通过”/” 实现通用匹配：

本例子中，9091服务为httpd

第一种情况：proxy_pass最后面没有斜杠,匹配路径有斜杠(/bbb/)，如图：

说明：proxy_pass最后面没有斜杠”/”，此时通过浏览器请求http://10.9.2.248/bbb/，那么实际访问的地址就是 http://10.9.2.248:9091/bbb/，会将匹配路径/bbb一起加过去

此时如果在http的目录页面目录htdocs中创建目录bbb，在bbb目录下创建文件index.html，然后即可实现正常访问，如图：

第二种情况： proxy_pass最后面有斜杠 “/”，匹配路径也有斜杠(/bbb/)，如图：

说明：proxy_pass最后面有斜杠”/”，此时通过浏览器请求http://10.9.2.248/bbb/，那么实际访问的地址就是 http://10.9.2.248:9091，会将/bbb抛弃的，如图：

第三种情况：proxy_pass后面还有其他路径但是最后没有 “/”， 匹配路径也有斜杠(/bbb/) ，如图：

说明，此时通过浏览器访问http://10.9.2.248/bbb/index.html，实际请求的是http://10.9.2.248/cxxindex.html(注意位置是默认路径下，不是ccc路径下，如果proxy_pass的路径为/ccc/ddd，那么实际请求的就是ccc路径下的cccindex.html)

在httpd的默认路径下(htdocs)创建文件cxxindex.html，然后访问，如图：

第四种情况： proxy_pass后面还有其他路径但是最后有 “/”， 匹配路径也有斜杠(/bbb/) ，如图：

说明：此时通过浏览器访问：http://10.9.2.248/bbb/index.html，实际访问的是http://10.9.2.248/ccc/index.html

在httpd默认路径下(htdocs)创建一个名称为ccc的文件夹，在内部定义一个index.html，然后访问，如图：

第五种情况：location匹配路径末尾没有 “/”，proxy_pass后面也没有”/”，如图：

说明：8081端口为httpd的服务器端口，如果匹配路径和proxy_pass后都没有”/”，那么此时访问http://10.9.2.248/bbb，默认将请求到http://127.0.0.1:8081/bbb/index.html的内容，此时在httpd默认路径htdocs下创建文件夹bbb，内部创建index.html，定义内容为：i am match bbb，通过IP请求如图：

更多内容参考链接地址：https://www.ywdevops.cn/index.php/2021/11/08/nginx-5/

阅读原文：原文链接