nginx.conf文件的server段下，location用于配置uri的命中规则和映射结果。

语法规则

语法规则：location [ = | ~ | ~* | ^~ | @ ] /uri/ { … }

=：进行常规字符精确匹配
^~：常规字符匹配，遵循最长匹配原则，一般用来匹配目录
~：区分大小写的正则匹配
~*：不区分大小写的正则匹配
!~ 和 !~*：分别为区分大小写不匹配，及不区分大小写不匹配的正则
/：通配符

匹配优先级

location的匹配规则有点复杂，先贴一段官方对优先级的约定：

To summarize, the order in which directives are checked is as follows:

Directives with the = prefix that match the query exactly. If found, searching stops.

All remaining directives with conventional strings, longest match first. If this match used the ^~ prefix, searching stops.

Regular expressions, in order of definition in the configuration file.

If #3 yielded a match, that result is used. Else the match from #2 is used.

蹩脚翻译：

精确匹配以"="为前缀的模式，如果命中就作为最终结果返回；
所有剩下的以常规字符串为模式的匹配，遵循最长匹配原则。如果命中，且该匹配使用"^〜"为前缀，就将匹配结果作为最终结果返回，否则继续执行第3步的正则匹配；
按照配置文件中定义的顺序进行正则匹配，注意，正则location强调在配置文件中的物理顺序；
如果第3条规则产生匹配的话，结果被使用。否则，使用第2条规则的结果。

这段官方的说明并不好消化理解，需要做进一步说明，首先要避免两个误区：

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 的最大前缀匹配结果”
《Nginx之location 匹配规则详解》，这篇博文作了非常详尽的匹配规则分析说明

为了方便记忆，将location匹配简化为3类：普通location内部匹配，正则location内部匹配，普通location与正则location匹配。规则继续拆分后得到下列单项：

优先匹配普通location，然后才会匹配正则location
普通location使用了"="或"^~"语法并且匹配成功，就停止后续匹配，将当前命中结果作为最终结果返回
第1条不满足的情况下，普通location遵循最长前缀匹配原则，如果精确匹配，则将当前命中结果作为最终结果返回，否则继续执行正则匹配；正则匹配若不命中，取普通匹配结果，否则正则匹配结果覆盖普通匹配结果
普通location内部匹配不关心location在配置文件中的编辑顺序，选最优解
正则location内部匹配关心location在配置文件中的编辑顺序，只要匹配到一条正则location ，就不再考虑编辑顺序靠后的location
正则 location 匹配让步普通location 的严格精确匹配结果；但覆盖普通 location 的最大前缀匹配结果

结合示例理解记忆（示例转自：https://www.cnblogs.com/sign-ptk/p/6723048.html
）：

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  
}

那么产生的效果如下：

访问根目录/，比如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/  
}

Nginx location匹配规则详解 [3]

Nginx location匹配规则详解 [3]

语法规则

匹配优先级