nginx location正则表达式+案例解析

1、nginx常用的正则表达式

• ^ ：匹配输入字符串的起始位置
• $ ：匹配输入字符串的结束位置
• *：匹配前面的字符零次或多次。如“ol*”能匹配“o”及“ol”、“oll”
• + ：匹配前面的字符一次或多次。如“ol+”能匹配“ol”及“oll”、“olll”，但不能匹配“o”
• ? ：匹配前面的字符零次或一次，例如“do(es)?”能匹配“do”或者“does”，”?”等效于”{0,1}”
• . ：匹配除“\n”之外的任何单个字符，若要匹配包括“\n”在内的任意字符，请使用诸如“[.\n]”之类的模式
• \ ：将后面接着的字符标记为一个特殊字符或一个原义字符或一个向后引用。如“\n”匹配一个换行符，而“$”则匹配“$”
• \d ：匹配纯数字[0-9] \s ：空白符 \w ：任意单词字符包括下划线[A-Za-z0-9_]
• {n} ：重复 n 次
• {n,} ：重复 n 次或更多次
• {n,m} ：重复 n 到 m 次
• [] ：定义匹配的字符范围
• [c] ：匹配单个字符 c
• [a-z] ：匹配 a-z 小写字母的任意一个
• [a-zA-Z0-9] ：匹配所有大小写字母或数字
• () ：表达式的开始和结束位置
• | ：或运算符

2、location

1、location匹配的分类：

1)、精准匹配：location = /test {…}
*完整的路径(必须有test )，一个字都不能少，也不能错
2)、一般匹配：location / {…}
*location = / {…}–所有
*location = /test {…}–包含test
3)、正则匹配：location ~ / {…}
*location ^~：前缀匹配，以什么为开头
*location ~：区分大小写进行匹配
*location ~：不区分大小写
*location !~：区分大小写，取反匹配
*location !~：不区分大小写，取反匹配

location 常用的匹配规则

• = ：进行普通字符精确匹配，也就是完全匹配。
• ^~ ：表示普通字符匹配。使用前缀匹配。如果匹配成功，则不再匹配其它 正则匹配location。
• ~ ：区分大小写的匹配。
• ~* ：不区分大小写的匹配。
• !~ ：区分大小写的匹配取非。
• !~* ：不区分大小写的匹配取非。

location匹配一旦匹配成功，不再向下继续匹配

优先级：
首先精确匹配 =
其次前缀匹配 ^~
其次是按文件中顺序的正则匹配 _或*
然后匹配不带任何修饰符的一般前缀匹配
最后是交给 / 通用匹配

精确匹配——正则匹配——一般匹配

完整的优先级：面试题

(location = 完整路径) > (location ^~ 路径) > (location ~,~* 正则顺序) > (location /部分前缀路径) > (location /)

首先看 优先级：精确= > 前缀^~ > 正则_,* > 一般 > 通用/

在没有精确匹配的时候，先看所有前缀的长度，取最长匹配的location；
如果最长的前缀匹配是带有~~的，则匹配，直接使用^~的location匹配用户的访问路径并跳转页面；如果最长的前缀匹配是不带^~的，则会继续看其它的正则匹配
前缀匹配看长度，最长的优先匹配；正则匹配看上下顺序，根据配置文件的配置由上往下依次匹配，匹配到即停止

2、案例

案例1
1）location = / {}

• =为精确匹配 / ，主机名后面不能带任何字符串，比如访问 / 和 /data，则 / 匹配，/data 不匹配
  再比如 location = /abc，则只匹配/abc ，/abc/或 /abcd不匹配。若 location /abc，则即匹配/abc 、/abcd/ 同时也匹配 /abc/。

2）location / {}

• 因为所有的地址都以 / 开头，所以这条规则将匹配到所有请求 比如访问 / 和 /data, 则 / 匹配， /data 也匹配，
  但后面前缀路径会和最长字符串优先匹配（最长匹配）

3）location /documents/ {}

• 匹配任何以 /documents/ 开头的地址，匹配符合以后，还要继续往下搜索其它 location
  只有其它 location后面的前缀路径没有匹配到时，才会采用这一条

4）location /documents/abc {}

• 匹配任何以 /documents/abc 开头的地址，匹配符合以后，还要继续往下搜索其它 location
  只有其它 location后面的前缀路径没有匹配到时，才会采用这一条

5）location ^~ /images/ {}

• 匹配任何以 /images/ 开头的地址，匹配符合以后，停止往下搜索正则，采用这一条

6）location ~* .(gif|jpg|jpeg)$ {}
**重要**

• 匹配所有以 gif、jpg或jpeg 结尾的请求
  然而，所有请求 /images/ (资源文件路径，项目打包后index.html文件内查看 关联路径，可修改（React:修改package.json 文件内的homepage:可更改路径）)下的图片会被 location ^~ /images/ 处理，因为 ^~ 的优先级更高，所以到达不了这一条正则

7）location /images/abc {}

• 最长字符匹配到 /images/abc，优先级最低，继续往下搜索其它 location，会发现 ^~ 和 ~ 存在

8）location ~ /images/abc {}

• 匹配以/images/abc 开头的，优先级次之，只有去掉 location ^~ /images/ 才会采用这一条

9）location /images/abc/1.html {}

• 匹配/images/abc/1.html 文件，如果和正则location ~ /images/abc/1.html 相比，正则优先级更高

案例2，有如下匹配规则：

location = / {  
   #规则A  （访问网站根目录才会走这比如http://localhost/）  =开头表示精确匹配
}  
location = /login {  
   #规则B（http://localhost/login）  
}  
location ^~ /static/ {  
   #规则C （http://localhost/static/a.html） ^~开头表示以常规字符串开头的url路径
}  
location ~ \.(gif|jpg|png|js|css)$ {  
   #规则D （访问 http://localhost/a.gif, http://localhost/b.jpg 将匹配规则D和规则E，但是规则D顺序优先，规则E不起作用，而 http://localhost/static/c.png 则优先匹配到 规则C） ~开头表示区分大小写的匹配
}  
location ~* \.png$ {  
   #规则E （访问 http://localhost/a.PNG 则匹配规则E， 而不会匹配规则D，因为规则E不区分大小写） ~*开头表示不区分大小写的正则匹配
}  
location !~ \.xhtml$ {  
   #规则F   !~开头表示区分大小写的不匹配
}  
location !~* \.xhtml$ {  
   #规则G  !~*开头表示不区分大小写的不匹配
}  
location / {  
   #规则H （http://localhost/register） 
}  

访问 http://localhost/a.xhtml 不会匹配规则F和规则G，http://localhost/a.XHTML不会匹配规则G，因为不区分大小写。规则F，规则G属于排除法，符合匹配规则但是不会匹配到，所以想想看实际应用中哪里会用到。

访问 http://localhost/category/id/1111 则最终匹配到规则H，因为以上规则都不匹配，这个时候应该是nginx转发请求给后端应用服务器，比如FastCGI（php），tomcat（jsp），nginx作为方向代理服务器存在。

那么产生的效果如下：

访问根目录/， 比如http://localhost/ 将匹配规则A

访问 http://localhost/login 将匹配规则B，http://localhost/register 则匹配规则H

访问 http://localhost/static/a.html 将匹配规则C

访问 http://localhost/a.gif, http://localhost/b.jpg 将匹配规则D和规则E，但是规则D顺序优先，规则E不起作用，而 http://localhost/static/c.png 则优先匹配到 规则C

访问http://localhost/a.PNG 则匹配规则E， 而不会匹配规则D，因为规则E不区分大小写。

访问 http://localhost/a.xhtml 不会匹配规则F和规则G，http://localhost/a.XHTML不会匹配规则G，因为不区分大小写。规则F，规则G属于排除法，符合匹配规则但是不会匹配到，所以想想看实际应用中哪里会用到。

访问http://localhost/category/id/1111则最终匹配到规则H，因为以上规则都不匹配，这个时候应该是nginx转发请求给后端应用服务器，比如FastCGI（php），tomcat（jsp），nginx作为方向代理服务器存在。

所以实际使用中，通常至少有三个匹配规则定义，如下：

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

3、(nginx的重定向) ReWrite语法

案例文件的最下面

案例1
案例2
案例3

重要

1、项目地址匹配了（资源文件需要查看，能否匹配）
方法：
对应不同的应用–（nginx:一个端口对应不同应用判断）
location ^~ /images/ {}
location ~* .(gif|jpg|jpeg)$ {}

• 匹配所有以 gif、jpg或jpeg 结尾的请求
  然而，所有请求 /images/ (资源文件路径，项目打包后index.html文件内查看 关联路径，可修改（React:修改package.json 文件内的homepage:可更改路径）)下的图片会被 location ^~ /images/ 处理，因为 ^~ 的优先级更高，所以到达不了这一条正则