Nginx配置文件location官方说明

官方文档：http://nginx.org/en/docs/http/ngx_http_core_module.html#location

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

根据请求uri来设置配置

进行匹配的目标是规范化的URI，规范化的URI是指在解码“%XX” 形式编码的文本、解析相对路径符号 “.” 和 “..”，以及将重复斜杠压缩为单斜杠以后的URI。

一个location能够由带前缀的字符串或者正则表达式来定义。正则表达式使用前置的“~*”修饰符 (不区分大小写匹配)，或者 “~” 修饰符(区分大小写匹配)来指定。为了找到与指定request匹配的location，Nginx首先使用前缀字符串定义的location进行匹配。其中，选择并记住匹配前缀最长的位置。 而后按正则表达式在配置文件中出现的顺序检查它们。 正则表达式的搜索在第一次匹配时终止，并使用相应的配置。若是没有找到与正则表达式匹配的，则使用前面提到的前缀位置的配置。

除了下面提到的一些例外，位置块能够嵌套。

对于不区分大小写的操做系统，例如macOS和Cygwin，与前缀字符串匹配会忽略大小写(0.7.7)。可是，比较仅限于一个字节区域设置。

正则表达式能够包含捕获(0.7.40)，稍后能够在其余指令中使用。

正则表达式能够包含捕获(0.7.40)，稍后能够在其余指令中使用。

若是最长前缀字符串匹配的location具备“^ ~”修饰符，那么正则表达式不检查。

此外，使用“ =”修饰符能够定义URI和位置的精确匹配。若是找到彻底匹配，则搜索终止。例如，若是/频繁发生“ ”请求，则定义“ 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。

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

若是位置由以斜杠字符结尾的前缀字符串定义，而且请求由 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;
}

（非官方补充：若是/user配置与/user/相同，就不用专门定义= /user）