译：
| Syntax: | location [ = | ~ | ~* | ^~ ] uri { ... }``location @name { ... } |
|---|---|
| Default: | — |
| Context: | server, location |
依据请求的URI进行配置。
在对以"%xx"形式的文本解码，对相对路径".“和”…"的格式化和两个或多个相邻斜杠压缩为单个斜杠后的规范URI执行匹配。
一个location可以被定义为一个前缀字符串或者一个正则表达式。正则表达式通过前缀"*"（忽略大小写）或者""（大小写敏感）修饰，在这些位置中，最长前缀字符串匹配的location会被选中和记住。然后会按照正则表达式在配置文件中出现的顺序进行正则表达式的匹配。在第一个正则表达式匹配上就会终止，并且相应的配置会被使用。如果没有匹配上正则表达式，前面记住的前缀字符串匹配的location的配置将会被使用。
location 块是可以嵌套的，以下提到一些例外。
对于不区分大小写的操作系统例如macOS和Cygwin，与前缀字符串匹配忽略大小写。然而，比较被局限于一字节的环境。
正则表达式可以包含捕获，捕获的内容可以被用在之后的其他指令中。
如果匹配的最长的前缀字符串的location有“^~"修饰，之后的正则表达式检查就不会进行了。
使用"=“修饰是定义一个严格匹配的URI和location。如果匹配上一个严格模式，搜索就会终止。例如，如果一个”/"请求经常发生，定义"location = /"将会快速处理这些请求。在第一个严格的location匹配上后就会终止搜索。这样的location显然不能包含嵌套location。
注：在0.7.1到0.8.41版本中，如果一个请求匹配了前缀字符串的location即使没有"=“或者”^~"修饰，搜索也会停止并且正则表达式也不会检查。
让我们通过一个例子进行说明：
location = / {
[ configuration A ]
}
location / {
[ configuration B ]
}
location /documents/ {
[ configuration C ]
}
location ^~ /images/ {
[ configuration D ]
}
location ~* \.(gif|jpg|jpeg)$ {
[ configuration E ]
}
“/“请求将会匹配 configuration A，”/index.html"请求将会匹配configuration B，”/documents/document.html"请求将会匹配configuration C，"/images/1.gif"请求将会匹配configuration D，"/documents/1.jpg"请求将会匹配configuration E。
"@"前缀作为前缀定义的location。这样的location不是用来处理常规请求的，而是用于请求重定向。它们也不能嵌套，也不能包含嵌套位置。
如果一个location通过前缀以斜杠结尾字符定义的，并且请求被 proxy_pass，fastcgi_pass，uwsgi_pass，scgi_pass，memcached_pass或grpc_pass之一处理，然后会执行特殊处理。在响应一个请求的URI等这个字符串但是没有斜杠，一个永久重定向的cod 301将会返回请求的URI并且带上斜杠。如果不想这样，一个严格匹配的URI和location可以像这样定义：
location /user/ {
proxy_pass http://user.example.com;
}
location = /user {
proxy_pass http://login.example.com;
}
注意点
- 通过字符串定义的location是从URI的path的前面开始匹配的，这就是为什么总强调前缀字符串的原因，不是URI的path中有一部分匹配上就行，必须要从path的头开始匹配，但是正则就没有这个限制。
- 关于^~匹配上就不向后就不向后进行正则的匹配了。这里要注意的是要求 ^~ 匹配上，就是在进行字符串搜索的时候 ^~ 是要被记住的那个location，也就是匹配上的最长前缀的location。
参考
