Nginx location 正则匹配规则

富士康质检员张全蛋

已于 2024-05-22 19:20:31 修改

阅读量2.5k

点赞数 1

分类专栏： Nginx 文章标签： nginx

于 2020-03-12 11:12:21 首次发布

本文链接：https://blog.csdn.net/qq_34556414/article/details/104813865

版权

Nginx 专栏收录该内容

93 篇文章

订阅专栏

本文深入探讨Nginx中Location指令的功能与用法，包括绝对匹配与前缀匹配的区别，以及正则表达式在Location中的应用。文章还详细解释了各种修饰符的作用，如波浪线、星号和等号，并提供了实例演示不同匹配方式的效果。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Location是什么？

Location是Nginx中的块级指令(block directive)，通过配置Location指令块，可以决定客户端发过来的请求URI如何处理（是映射到本地文件还是转发出去）及被哪个location处理。

匹配模式	分为两种模式：绝对匹配：调用的请求Path固定为创建时填写的API请求Path。前缀匹配：调用的请求Path将以创建时填写的API请求Path为前缀，支持接口定义多个不同Path。例如，请求路径为/test/AA，使用前缀匹配时，通过/test/AA/CC可以访问，但是通过/test/AACC无法访问。说明：使用前缀匹配时，匹配剩余的路径将透传到后端。例如，使用前缀匹配，前端请求路径定义为/test/，后端请求路径定义为/test2/，通过/test/AA/CC访问API，则后端收到的请求url为/test2/AA/CC。

Location 基本语法

~波浪线代表进行大小写的匹配，~* 波浪线加星号代表是不区分大小写的。波浪线后面的是正则表达式。

\.(PNG|jpg)$ 这样表示uri会以PNG或者jpg形式结束。

修饰符(modifier) location [ = | ~ | ~* | ^~ ] uri { ... }
//中括号中为修饰符，可以不写任何参数，此时称为一般匹配，也可以写参数，location根据

不同的修饰符可以分为两大类

1. 前缀 location(prefix location):
无修饰符的普通location [普通匹配]
带=的精准匹配location [精准匹配]

2.带^~的非正则表达式location [忽略正则匹配] 只需匹配uri部分
location ^~ /img/ {
       [ configuration ] 
}
以 /img/ 开头的请求，都会匹配上
http://www.lutixia.com/img/lutixia.jpg   [成功]
http://www.lutixia.com/img/lutixia.png [成功]
3.正则表达式location(regular expressions location 带波浪号):
~ 区分大小写的正则location [正则匹配]
location ~ /LUTIXIA/ {
         [ configuration ] 
    }
    #请求示例
    #http://www.lutixia.com/LUTIXIA/  [成功]
    #http://www.lutixia.com/lutixia/  [失败]


# ~ : 正则表达式,区分大小写
server{
        listen          92;
        server_name     localhost;
 
        #假设这里要访问http://192.168.217.129:92/xpfStatic/img/face1.png,
        #由于访问路径区分大小写，所以即使服务器img下有face1.png图片资源，也访问不了。
        #必须是大写的face1.PNG才能访问
        location ~ \.(gif|PNG|bmp|jpg|jpeg){
            root /home;
        }
}
~* 不区分大小写的正则location [正则匹配] 这里要注意忽略大小写的意思是请求的字符大小写都可以
location ~* /LUTIXIA/ {
           [ configuration ] 
}
# 则会忽略 uri 部分的大小写
#http://www.lutixia.com/LUTIXIA/  [成功] 可以成功匹配，但是目录中要LUTIXIA文件
#http://www.lutixia.com/lutixia/  [成功] 可以成功匹配，但是目录中要lutixia文件


# ~* : 正则表达式,不区分大小写
server{
        listen          93;
        server_name     localhost;
 
        #假设这里要访问http://192.168.217.129:93/xpfStatic/img/face1.png,
        #即使正则表达式里写的是大写PNG，但只要服务器里有face1.png一样可以匹配的到。
        location ~* \.(gif|PNG|bmp|jpg|jpeg){
            root /home;
        }
 
}
location ~ \.(PNG|jpg)$ 区分大小写意味着你得写上大写的PNG或者jpg才能匹配到该location当中规则。
location ~* \.(PNG|jpg)$ 不区分大小写意味着，不管写上小写的PNG或者jpg都能够匹配到该location当中规则。

        location / {
          root /usr/local/nginx/html;
          index index.html;
        }

        location ~* \.(PNG|jpg)$ {
          root myweb;
          allow all;
        }

只要uri的结尾不以png和jpg结尾就会匹配到第一个location，去目录下面找html里面内容。如果以png或者jpg结尾就会找到第二个location。

        location / {
          root /usr/local/nginx/html;
          index index.html;
        }

        location ~ \.(PNG|jpg)$ {
          root myweb;
          allow all;
        }

如果访问是192.168.179.2:80/1.png匹配的是第一个location而不是第二个（访问的是html目录下面的1.png），因为第二个区分大小写。

区分大小写

下面使用echo模块来测试，测试一下匹配到哪个location，location里面的jpg资源是可以不存在的，即使用echo打印看调用哪个模块

location ~/jfedu.jpg {
           echo "this is ~/jfedu.jpg";
       }

location ~/JFEDU.jgp {
           echo "this is ~/JFEDU.jpg";
          }

[root@www ~]# curl 192.168.179.99/jfedu.jpg
this is ~/jfedu.jpg
[root@www ~]# curl 192.168.179.99/JFEDU.jpg
this is ~/JFEDU.jpg
可以看到是区分大小写的，大小写不一样匹配到的location是不一样的

普通玩法就是具体的路径和页面

下面都是跟着的就是普通字符串，其实效果都是一样的。

        location ~ /aatest {
          root /usr/local/nginx/html;
        }

        location ~ /aatest/ {
          root /usr/local/nginx/html;
        }

        location ~ aatest {
          root /usr/local/nginx/html;
        }

/*也是正则表达，这个就是在aatest下面所有的资源都可以访问到。

       location ~ /aatest/* {
          root /usr/local/nginx/html;
        }

不区分大小写

location ~* /jfedu.jpg {
           echo "this is ~/jfedu.jpg";
       }
[root@www ~]# curl 192.168.179.99/jfedu.jpg
this is ~/jfedu.jpg
[root@www ~]# curl 192.168.179.99/JFEDU.jpg
this is ~/jfedu.jpg
[root@www ~]# curl 192.168.179.99/jfedu.JPG
this is ~/jfedu.jpg
这样写一个location就行了，不用像上面大小写敏感写两个location。

下面防盗链也使用了不区分大小写

location ~* \.(gif|jpg|png|swf|flv)$ {

valid_referers none blocked lutixia.net *.jfedu.net;

root /usr/local/nginx/html;

if ($invalid_referer) {
    return 403;
}}

”@” nginx内部跳转

location /img/ {
error_page 404 @img_err;
}
location @img_err {
}
以 /img/ 开头的请求，如果链接的状态为 404。则会匹配到 @img_err 这条规则上

^~ 忽略正则匹配

^~，只匹配以 uri 开头，匹配成功以后，会停止搜索后面的正则表达式匹配

 location  ^~/img/{
         echo "this is img";
        }

只要uri以/img/ 开头的请求，都会匹配上，不管后面是什么类型的资源
[root@www ~]# curl 192.168.179.99/img/
this is img
[root@www ~]# curl 192.168.179.99/img/abc
this is img

优先级问题几则

（1）精准匹配优先级最高

location ~* /img/jfedu.jpg {
           echo "this is ~*/jfedu.jpg";
       }
location ~ /img/jfedu.jpg {
           echo "this is ~jfedu.jpg";
       }
location = /img/JFEDU.jpg {
           echo "this is =/JFEDU.jpg";
       }
location  ^~/img/{
         echo "this is ^~/img/";
        }
[root@www ~]# curl 192.168.179.99/img/JFEDU.jpg  --可以看到先匹配到的是精准匹配，正则和忽略正则优先级都没精准高
this is =/JFEDU.jpg

（2）忽略正则比正则优先级高

location ~* /img/jfedu.jpg {
           echo "this is ~*/jfedu.jpg";
       }
location ~ /img/jfedu.jpg {
           echo "this is ~jfedu.jpg";
       }
location  ^~/img/{
         echo "this is ^~/img/";
        }
这里就剩下正则匹配和忽略正则匹配
[root@www ~]# curl 192.168.179.99/img/jfedu.jpg --可以看到先匹配到的是忽略正则，忽略正则优先级比正则要高
this is ^~/img/

（3）正则之内优先级和顺序有关

location ~* /img/jfedu.jpg {
           echo "this is ~*/jfedu.jpg";
       }
location ~ /img/jfedu.jpg {
           echo "this is ~jfedu.jpg";
       }
[root@www ~]# curl 192.168.179.99/img/jfedu.jpg  --可以看到正则之内优先级和顺序有关
this is ~*/jfedu.jpg

location命中过程

1.先进行精准匹配，如果命中立即返回结果并结束解析的过程

2.精准匹配未命中判断普通匹配，如果命中多个会记录下"最长的"命中结果，但不会结束解析

3.继续判断正则匹配,按照正则匹配设置的规则正则表达式进行匹配,如果有多个正则匹配则由上到下进行匹配,一旦匹配成功一个会立即返回结果并结束解析.

ps:普通匹配的前后顺序是无所谓的,因为记录的是最长的结果,而正则匹配是按从上到下匹配的,这个需要注意!!!

优先级精准匹配>非正则匹配>正则匹配由上到下>普通匹配

实际使用建议

实际使用中，个人觉得至少有三个匹配规则定义，如下：

（1）直接匹配网站根，通过域名访问网站首页比较频繁，使用这个会加速处理，官网如是说。这里是直接转发给后端应用服务器了，也可以是一个静态首页，第一个必选规则

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

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

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

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

（3）第三个规则就是通用规则，用来转发动态请求到后端应用服务器
非静态文件请求就默认是动态请求，自己根据实际把握，毕竟目前的一些框架的流行，带.php,.jsp后缀的情况很少了
location / {
proxy_pass  http://tomcat:8080/
}