前言

在前面的文章中，我们做了很多铺垫，比如Nginx配置文件的结构，PCRE正则表达式等等，只有大家弄明白了这些东西，才能深入的学习后面的知识。
我们一直在强调，Nginx是一个优秀的HTTP服务器，那么作为一个服务器，它必须要能够根据用户的不同请求进行不同的处理，location指令就是为了完成这个需求的。

location的用法

location是nginx的一大利器，该指令可以让根据请求的URI分别进行不同的处理，比如如果用户请求的是一个图片，那么需要到pic目录下面寻找，如果请求的是视频，那么需要到video目录下面寻找，这样我们就可以把不同类型的文件分开存储，方便了管理。
我们先来看一下location的语法规则，非常的简单：

Syntax:	location [ = | ~ | ~* | ^~ ] uri { ... }
        location @name { ... }
Default:	—
Context:	server, location

我把这几种情况进行了分类:

1. 普通匹配(没有任何修饰符)
2. 精确匹配（以"="开头）
3. 最长前缀匹配(以"^~"开头)
4. 正则匹配
   • 区分大小写的正则(以~开头)
   • 忽略大小写的正则(以~*开头)
5. 内部location(以@开头)

匹配顺序

我在工作过程中发现有很多人对Location的匹配顺序搞不清楚，所以这节课我就会以着重给大家分析一下如何根据用户请求的URI进行Location匹配。

上图是我画的一个流程图，从这个流程图中我们可以清晰的看到location的匹配顺序。
从流程图中我们可以总结如下几点:

1. 精确匹配的优先级最高。
2. 如果没有精确匹配，那么就会对配置文件中的所有非正则location进行匹配，找到最长匹配。3. 如果最长匹配是以^~开头，那么就返回该匹配结果。
3. 对正则匹配逐个进行匹配，如果匹配成功，则返回正则location，如果不成功，则返回第2步匹配的最长匹配结果。

划重点了：

1. 第2步是要对所有的非正则location都要进行匹配，也就是说，非正则匹配与location出现的顺序无关
2. 第四步是对正则location逐个匹配，如果成功就直接返回，所有正则表达式结果与配置文件中出现的顺序有关系。

例子走起来

我们用一个实际的例子来说明整个过程：

上面是我们的一个配置文件，我们测试一下，看看是不是按照我们图中的顺序进行匹配的。

精确匹配

从结果分析，我们访问的路径是/first，虽然配置文件中精确匹配的location在配置文件的最后面，但还是匹配到了精确匹配，这也说明精确匹配的优先级是最高的。

最长前缀匹配

从结果中可以看出来，返回的结果是最长前缀匹配，并没有进行正则匹配。

正则匹配

我们首先按照流程图可以知道，当前请求的最长前缀匹配应该是/abc/def，但是为什么返回了 ~ ^/first/a呢？
因为后来进行了正则匹配，并且~ ^/first/a是第一个正则匹配，匹配成功之后直接返回了，所以后面的~ ^/first/abc正则没有被执行。

这里有两点小建议：

1. 因为精确匹配的优先级最高，比如根域名这些经常被访问的URI建议使用精确匹配。
2. 正则匹配与顺序有关，所以建议越详细的正则应该越靠前。

小结

好了，关于 Location 查找我们就先讲到这里，希望对你有所帮助~