location匹配规则

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

location块根据请求的URI配置Nginx服务器的行为。

在对进行URI匹配前，先将URI进行标准化处理， 包括解码“%XX”形式的文本、解析相对路径组件“.”和“..”，以及将两个或多个相邻的斜杠压缩为一个斜杠。然后再对标准化后的URI进行匹配。

一个location可以通过前缀字符串或正则表达式来定义。如果要使用正则表达式，需要使用 [ ~* ] 或 [ ~ ] 修饰符来指定大小写敏感或不敏感匹配。当Nginx接收到一个请求时，它会首先检查所有前缀字符串匹配的location，选择最长匹配的前缀，并记住它。然后按照它们在配置文件中出现的顺序检查所有正则表达式，直到找到第一个匹配的表达式为止。如果没有找到匹配的正则表达式，则使用之前记住的前缀location的配置。

location 块可以嵌套，但有一些例外情况。

对于macOS和Cygwin等不区分大小写的操作系统，与前缀字符串匹配会忽略大小写（0.7.7）。然而，但比较受到一字节本地化的限制。

正则表达式可以包含捕获(0.7.40) ，以后可以在其他指令中使用。

如果最长的匹配前缀位置具有“ ^~”修饰符，则不检查正则表达式。

此外，使用“=”修饰符可以定义URI和位置的精确匹配。如果找到精确匹配，则搜索终止。例如，如果“/”请求经常发生，定义“location = /”将加快处理这些请求的速度，因为搜索会在第一次比较后立即终止。这样的位置显然不能包含嵌套 location。

在0.7.1到0.8.41的版本中，如果一个请求匹配了不带“=”和“^~”修饰符的前缀位置，搜索也会终止，正则表达式也不会被检查。

让我们通过一个例子来说明以上内容：

location = / {
    [ configuration A ]
}

location / {
    [ configuration B ]
}

location /documents/ {
    [ configuration C ]
}

location ^~ /images/ {
    [ configuration D ]
}

location ~* \.(gif|jpg|jpeg)$ {
    [ configuration E ]
}

• “/”请求将匹配配置A
• “/index.html”请求将匹配配置B
• “/documents/document.html”请求将匹配配置C
• “/images/1.gif”请求将匹配配置D
• “/documents/1.jpg”请求将匹配配置E

“@”前缀定义了一个命名位置。这样的位置不用于常规请求处理，而是用于请求重定向。它们不能嵌套，也不能包含嵌套位置。

如果一个 location 是由以 “/” 字符结尾的前缀字符串定义的，并且请求由以下之一的处理：proxy_pass，fastcgi_pass，uwsgi_pass，scgi_pass，memcached_pass，或grpc_pass，则将执行特殊处理。对于URI等于此字符串但没有尾部斜杠的请求，将返回301代码的永久重定向，重定向的地址就是原URI再加一个斜杠。 如果不需要这样做，则可以像这样定义URI和位置的确切匹配：

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

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

一个location匹配可视化网站