location 匹配规则

简单理解就是 ：
以~ 开头的是 正则匹配，其他的是普通匹配, 普通匹配是最大前缀匹配例如 location / 就是说明前缀是 / 的就一定能匹配上，
如果有多个匹配上那么哪个节点是在最终结果？有几种情况
1，全匹配，就是 location 后面的 字符串和 uri一模一样，这种通常是普通匹配
2，正则匹配，就是 location后面的字符串是一个正则表达式和 uri匹配上
3，普通匹配，就是location 后面的字符串和 uri 从左边开始匹配，有的匹配多有的匹配少，uri肯定是用 / 开始（访问a.test.com/index.php，其实是两部分 a.test.com 和 /index.php ）
以上这些如果都匹配上了那么最终结果顺序是 先使用 全匹配 ，如果没有使用正则匹配如果再没有使用普通匹配，如果普通匹配有多个那么就是匹配最多的那个是最终结果
走到匹配的区间之后再去按照各自的区间配置去转发到fastcgi ,如果没有写设置就是走默认的

从手册中粘贴过来的例子，很棒完全解释了怎么匹配
位置可以由前缀字符串或正则表达式定义。使用前面的“ ~*”修饰符（对于不区分大小写的匹配）或“ ~”修饰符（对于区分大小写的匹配）指定正则表达式。为了找到与给定请求匹配的位置，nginx首先检查使用前缀字符串（前缀位置）定义的位置。其中，选择并记住具有最长匹配前缀的位置。然后按照它们在配置文件中的出现顺序检查正则表达式。正则表达式的搜索在第一次匹配时终止，并使用相应的配置。如果未找到与正则表达式的匹配，则使用先前记住的前缀位置的配置。
location 块可以嵌套，下面提到一些例外。
对于不区分大小写的操作系统（如macOS和Cygwin），与前缀字符串匹配会忽略大小写（0.7.7）。但是，比较仅限于单字节语言环境。
正则表达式可以包含稍后可以在其他指令中使用的捕获（0.7.40）。
如果最长匹配前缀位置具有“ ^~”修饰符，则不检查正则表达式。
此外，使用“ =”修饰符可以定义URI和位置的精确匹配。如果找到完全匹配，则搜索终止。例如，如果/频繁发生“ ”请求，则定义“ location = /”将加速这些请求的处理，因为搜索在第一次比较之后立即终止。这样的位置显然不能包含嵌套位置。
在0.7.1到0.8.41的版本中，如果请求与前缀位置匹配而没有“ =”和“ ^~”修饰符，则搜索也会终止，并且不会检查正则表达式。
让我们通过一个例子来说明以上内容：
location = / {
[配置A]
}

地点 / {
[配置B]
}

location / documents / {
[配置C]
}

位置^〜/ images / {
[配置D]
}

location〜* \。（gif | jpg | jpeg）$ {
[配置E]
}

“ /”请求将匹配配置A，“ /index.html”请求将匹配配置B，“ /documents/document.html”请求将匹配配置C，“ /images/1.gif”请求将匹配配置D，并且“ /documents/1.jpg”请求将匹配配置E.
“ @”前缀定义命名位置。这样的位置不用于常规请求处理，而是用于请求重定向。它们不能嵌套，也不能包含嵌套位置。
如果位置由以斜杠字符结尾的前缀字符串定义，并且请求由 proxy_pass， fastcgi_pass， uwsgi_pass，scgi_pass， memcached_pa​​ss或 grpc_pass之一处理，则执行特殊处理。为了响应URI等于此字符串的请求，但没有尾部斜杠，带有代码301的永久重定向将返回到请求的URI，并附加斜杠。如果不需要，可以像下面这样定义URI和位置的完全匹配：
location / user / {
proxy_pass http://user.example.com;
}

location = / user {
proxy_pass http://login.example.com;
}