Nginx的Location到底是怎么匹配的?
引言
Nginx作为一个优秀且流行的七层负载均衡软件，大量应用在互联网公司的流量入口。随着OpenResty、Kong、APISIX等Nginx生态软件的流行，Nginx也被应用到了更多的领域。
对于普通的Nginx用户来说，最常见的操作就是配置Location。当一个server配置块有多条location，并且使用了不同的修饰符时，你是否经常遇到请求实际匹配location和自己期望的location不一致的情况呢？
今天我将详细说明Location的匹配逻辑，希望你在阅读之后能够更从容的使用Nginx。
配置语法介绍
首先，我们来了解一下location指令的配置语法：
location @name { ... }
location [ = | ~ | ~* | ^~ ] uri { ... }第一种配置语法，定义的是一个命名location，不处理常规的请求，只做内部的重定向使用。例如，error_page 404 = @fallback ，@fallback就是一个命名location。
第二种配置语法，在实际使用时的差异，在于location指令和uri之间的修饰符，一共有5种，下面分别介绍他们的含义：
- 使用=修饰符。在所有location中优先级最高，一旦匹配，会立即停止搜索其它location，开始执行location中的配置。
- 使用^~修饰符。注意，这个修饰符是普通前缀字符串匹配，不是正则修饰符。如果请求匹配到的最长前缀字符串location使用这个修饰符，将不再检查正则表达式location。
- 使用~或~*修饰符。这2个修饰符都是正则修饰符，后面uri可以使用正则表达式。~*表示不区分uri中的大小写，而~表示区分大小写。多个正则Location，在配置文件中的顺序代表了优先级，越靠前的优先级越高，一旦匹配到一个正则location，将不再搜索其它正则location，并使用匹配的location。
- 不使用修饰符。做普通前缀字符串匹配。如果请求可以匹配到多个普通前缀字符串location，将高优使用前缀匹配最长的location。
匹配流程说明
这里，我再做一个总结，帮助你更好的理解匹配流程。
一个请求进入server配置块之后，如果能匹配到一个=修饰的location，则直接使用这个location的配置。
如果无法匹配到=修饰的location，再看是否能匹配到一个最长前缀字符串location，且这个location使用了^~修饰符，如果能匹配，则直接使用这个location的配置。
如果无法匹配到使用了^~修饰符的最长前缀字符串location，那么再看能否匹配到一个正则表达式location，一旦匹配到就会使用这个location。
如果3种修饰符的location都没有匹配到，再搜索不使用修饰符的普通前缀字符串location，并使用前缀匹配最长的location。
如果所有的location都不能匹配，Nginx将向客户端返回404响应。
匹配流程图
下面再画一张流程图，帮助大家更好的理解匹配流程。
欢迎关注我的头条号@程序员地瓜, 及时获取最新发布动态。阅读文章过程中有任何问题，欢迎在评论区留言，我会及时回复。