谈一下nginx location 匹配优先级，为什么设了反向代理不生效的问题

作为前端开发来说，部署项目时，nginx反向代理用的相对较多，有时候反向代理并不会生效，我们来分析一下原因

在nginx中，可以使用location指令来匹配请求的URL，并根据匹配规则来选择对应的配置块进行处理。当nginx接收到一个请求时，会按照一定的优先级顺序来匹配location，具体的优先级如下：

精确匹配（=location = /path）：精确匹配优先级最高，只有当请求的URL与指定的路径完全一致时，才会触发该location块。

前缀匹配（location /path/）：如果没有精确匹配，nginx会寻找最长的前缀匹配，即请求的URL以指定的路径开头时，就会触发该location块。

正则表达式匹配（location ~ pattern）：如果没有前缀匹配，nginx会按照配置文件中出现的顺序，逐个匹配正则表达式类型的location，并选择第一个匹配成功的location块。

不带修饰的前缀匹配（location /path）：如果以上规则都没有匹配成功，nginx会选择这种形式的location进行处理。

需要注意的是，一旦匹配成功，nginx将会停止继续匹配其他location块，因此在配置location时需要特别注意顺序和匹配规则，以免造成意外的匹配结果。

最常见的问题。我有两个反向代理

#1
localtion /packageSoft {
	proxy_pass 127.0.0.1:8000;
}
#2
location /packageSoftTest {
	proxy_pass 127.0.0.1:9000;
}

你会惊奇的发现 packageSoftTest 是失效的
这就是因为使用了 “不带修饰的前缀匹配”
导致我们在请求 #2 packageSoftTest 时
正好匹配到了 #1 的packageSoft 。
所以请求就会走到 127.0.0.1:8000;