作为web服务器，能根据不同的url进行不同的处理算是nginx的一大主要功能，而这种路由选择都是通过配置文件中的location来完成的。这一节我们就来看看location是如何工作的。

基本格式

首先来看看默认配置是怎么样的

    server {
        listen       80 default_server;
        listen       [::]:80 default_server;
        server_name  _;
        root         /usr/share/nginx/html;
        # Load configuration files for the default server block.
        include /etc/nginx/default.d/*.conf;
        location / {
        }
        error_page 404 /404.html;
            location = /40x.html {
        }
        error_page 500 502 503 504 /50x.html;
            location = /50x.html {
        }
    }

location字段位于server字段中，在该server中起到路由的作用，语法规则如下

location [ = | ~ | ~* | ^~ ] url { ... }

location关键字后面接一个可选的修饰符，在后面接匹配条件，最后是一个大括号里面放要执行的动作。

一个server字段中可以有多个location字段，请求进来以后nginx会按照一定的优先级顺序去对这些location进行匹配，最后按照最优匹配的动作去执行。

如果没有特别指明动作，就是将请求的路径附加在root配置后面，返回对应的静态资源。

两种匹配方式

上面的基本语法中的url有两种写法，一种是前缀字符（prefix string），另一种是正则表达式（regular expression）。

前缀字符

当请求的url中的路径部分，也就是ip和端口后面开始的那部分，以location中定义的前缀开始的话，就认为满足匹配。

例如有如下配置

location /some/path/ {
    #...
}

那么当请求的路径为 /some/path/xiaofu.mp3 的时候就满足匹配，但是如果请求的路径为 /some/other/path/xiaofu.mp3 的话就不满足匹配

正则表达式

用 【~】 来表示区分大小写的正则表达式，用 【~* 】来表示不区分大小写的正则表达式。

下面的这个配置就表示请求的url中任意位置包含 .html 或者 .htm 都满足匹配

location ~ \.html? {
    #...
}

匹配优先级

上面一共有四种修饰符，我们知道了【~】 和【 ~* 】是用于正则表达式的，还有两个有是干嘛的呢？

这就涉及到匹配的优先级了。

【= 】表示精确匹配，【^~】 表示最佳匹配，两者都对应前缀字符匹配规则，看了下面的匹配顺序就了解它们俩是干嘛用的了。

1. 首先尝试匹配所有的前缀字符规则，以最长的重合为最优匹配

2. 如果有 【=】 对应的精确匹配满足，也就是说请求的路径和匹配规则完全相同，就直接用精确匹配的行为，不继续进行其余任何匹配了

3. 如果有的话，保存最长重合的前缀字符匹配。如果最长重合的前缀字符匹配有^~装饰符，不再查找正则匹配规则，按最长前缀匹配的行为

4. 依次进行正则匹配，以第一个匹配的为最优匹配。正则匹配的优先级高于前缀字符匹配，直接使用该正则匹配的行为

5. 如果没有满足条件的正则匹配，使用前面保存的最长前缀匹配的行为

6. 如果前缀符号和正则都没有匹配，返回404

基于以上的匹配顺序，可以有下面的一些实际操作建议

• 将频繁访问的路径用=来做精确匹配，可以大量节约匹配时间

• 因为正则匹配是从前往后按照第一个为准，所以正则匹配的前后顺序很重要，通常是越细致的越靠前

实际操作验证

说了这么多，来上手实际操作一下。

修改配置如下

location = / {
    return 601;
}       
            
location / {
    return 602;
}
location /user/ {
    return 603;
}
location ^~ /images/ {
    return 604;
}
location ~* \.(gif|jpg|jpeg)$ {
    return 605;
}

这里我没有准备实际的返回资源，而是用5个不同的返回码来区分匹配结果。

测试下语法正确性

(base) [root@ai-therm ~]# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

然后重新载入一下配置

(base) [root@ai-therm ~]# systemctl reload nginx

从另一台机器上进行curl测试。

如果直接访问【/】，会因为精确匹配而不再继续往下，返回601

root@control-plane-1:~# curl -I 172.29.56.178/
HTTP/1.1 601 
Server: nginx/1.16.1
Date: Sat, 30 May 2020 16:20:55 GMT
Content-Length: 0
Connection: keep-alive

如果访问/user/xiaofu.mp3会因为没有合适的正则匹配而采用最长前缀批匹配返回603

root@control-plane-1:~# curl -I 172.29.56.178/user/xiaofu.mp3
HTTP/1.1 603 
Server: nginx/1.16.1
Date: Sat, 30 May 2020 16:26:34 GMT
Content-Length: 0
Connection: keep-alive

如果访问/user/xiaofu.jpg就会因为正则匹配优先级更高而返回605

root@control-plane-1:~# curl -I 172.29.56.178/user/xiaofu.jpg
HTTP/1.1 605 
Server: nginx/1.16.1
Date: Sat, 30 May 2020 16:26:38 GMT
Content-Length: 0
Connection: keep-alive

如果访问/images/xiaofu.jpg就会因为最佳匹配而忽略正则匹配规则返回604

root@control-plane-1:~# curl -I 172.29.56.178/images/xiaofu.jpg
HTTP/1.1 604 
Server: nginx/1.16.1
Date: Sat, 30 May 2020 16:29:06 GMT
Content-Length: 0
Connection: keep-alive

最后如果访问/test/xiaofu.html会因为没有别的匹配而只能进行/匹配返回602

root@control-plane-1:~# curl -I 172.29.56.178/test/xiaofu.html
HTTP/1.1 602 
Server: nginx/1.16.1
Date: Sat, 30 May 2020 16:33:55 GMT
Content-Length: 0
Connection: keep-alive
1

关于url结尾的【/】

• 如果是location中的匹配规则，后面是否加【/】没有任何影响

• 如果是请求的url中路径的根目录，例如 http://1.2.3.4 和 http://1.2.3.4/ 是没有区别的，因为浏览器会默认帮我们加上这个【/】

• 非根目录下的/有无影响较大。例如 http://1.2.3.4/some/path/ 会去 /some/path/ 目录下寻找默认文件进行返回，而 http://1.2.3.4/some/path 则会去 /some/ 目录下返回名叫 path 的文件，如果找不到才会在末尾再加上【/】进行重定向继续查找 /some/path/ 目录下的默认文件

总结

• 先进行前缀字符串匹配，再进行正则匹配。但是正则匹配优先级更高。

• 前缀字符串按照最长匹配选择最优匹配，而正则按照先后顺序选择最优匹配。所以正则匹配规则要注意先后顺序，越精细的越靠前

• 对于频繁访问的url，使用精确匹配【=】来加快返回速度