Fork me on GitHub

Nginx 关于 location 的匹配规则

发表于 | 阅读量 次
| 字数统计: 1,258 | 阅读时长 ≈ 5

关于 location的匹配顺序的常见误区

  1. location 的匹配顺序是“先匹配正则，再匹配普通”。

    矫正：location 的匹配顺序其实是“先匹配普通，再匹配正则”。造成这种误解的原因是：正则匹配会覆盖普通匹配。

  2. location 的执行逻辑跟 location 的编辑顺序无关。

    矫正：这句话不全对，“普通 location ”的匹配规则是“最大前缀”，因此“普通 location ”的确与 location 编辑顺序无关；但是“正则 location ”的匹配规则是“顺序匹配，且只要匹配到第一个就停止后面的匹配”；“普通location ”与“正则 location ”之间的匹配顺序是？
    先匹配普通 location ，再“考虑”匹配正则 location 。注意这里的“考虑”是“可能”的意思，也就是说匹配完“普通 location ”后，有的时候需要继续匹配“正则 location ”，有的时候则不需要继续匹配“正则 location ”。

两种情况下，不需要继续匹配正则 location ：

  1. 当普通 location 前面指定了“ ^~ ”，特别告诉 Nginx 本条普通 location 一旦匹配上，则不需要继续正则匹配；
  2. 当普通location 恰好严格匹配上，不是最大前缀匹配，则不再继续匹配正则。

总结一句话： “正则 location 匹配让步普通 location 的严格精确匹配结果；但覆盖普通 location 的最大前缀匹配结果”。

location 语法规则

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

  • = 开头表示精确匹配
  • ^~ 开头表示uri以某个常规字符串开头，理解为匹配 url路径即可。nginx不对url做编码，因此请求为/static/20%/aa，可以被规则^~ /static/ /aa匹配到（注意是空格）。
  • ~ 开头表示区分大小写的正则匹配
  • ~* 开头表示不区分大小写的正则匹配
  • !~和!~*分别为区分大小写不匹配及不区分大小写不匹配 的正则
  • / 通用匹配，任何请求都会匹配到。
    多个location配置的情况下匹配顺序为（参考资料而来，还未实际验证，试试就知道了，不必拘泥，仅供参考）:
    首先匹配 =，其次匹配^~, 其次是按文件中顺序的正则匹配，最后是交给 / 通用匹配。当有匹配成功时候，停止匹配，按当前匹配规则处理请求。

nginx location 官方详解地址:http://nginx.org/en/docs/http/ngx_http_core_module.html#location

例子，有如下匹配规则：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
location = / {
   #规则A
}
location = /login {
   #规则B
}
location ^~ /static/ {
   #规则C
}
location ~ \.(gif|jpg|png|js|css)$ {
   #规则D
}
location ~* \.png$ {
   #规则E
}
location !~ \.xhtml$ {
   #规则F
}
location !~* \.xhtml$ {
   #规则G
}
location / {
   #规则H
}

那么产生的效果如下：

  1. 访问根目录 / ， 比如 http://localhost/ 将匹配 规则A
  2. 访问 http://localhost/login 将匹配 规则B，http://localhost/register 则匹配 规则H
  3. 访问 http://localhost/static/a.html 将匹配 规则C
  4. 访问 http://localhost/a.gif, http://localhost/b.jpg 将匹配 规则D 和 规则E，但是 规则D 顺序优先，规则E 不起作用，而 http://localhost/static/c.png 则优先匹配到 规则C
  5. 访问 http://localhost/a.PNG 则匹配 规则E，而不会匹配 规则D，因为 规则E 不区分大小写。
  6. 访问 http://localhost/a.xhtml 不会匹配 规则F 和 规则G，http://localhost/a.XHTML 不会匹配 规则G，因为不区分大小写。规则F，规则G 属于排除法，符合匹配规则但是不会匹配到，所以想想看实际应用中哪里会用到。
  7. 访问 http://localhost/category/id/1111 则最终匹配到 规则H，因为以上规则都不匹配，这个时候应该是 nginx 转发请求给后端应用服务器，比如 FastCGI（php），tomcat（jsp），nginx 作为方向代理服务器存在。

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

第一个必选规则

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

1
2
3
location = / {
    proxy_pass http://tomcat:8080/index
}

第二个必选规则

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

1
2
3
4
5
6
location ^~ /static/ {
    root /webroot/static/;
}
location ~* \.(gif|jpg|jpeg|png|css|js|ico)$ {
    root /webroot/res/;
}

第三个规则就是通用规则

用来转发动态请求到后端应用服务器
非静态文件请求就默认是动态请求，自己根据实际把握
毕竟目前的一些框架的流行，带.php,.jsp后缀的情况很少了

1
2
3
location / {
    proxy_pass http://tomcat:8080/;
}

当定义某个网站既有默认首页，又需要转发动态请求到后端服务器的时候，如果不使用如下location 语句指定页面路径

1
2
3
location = / {	
    root /path/to/html;
}

而是仅使用

1
2
3
location / {
    proxy_pass http://tomcat:8080/;
}

访问首页会返回404错误代码！