Nginx小记之location

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

location匹配是针对一个标准化后的URI进行的，标准化可能有如下几种操作：

解码 “@xx” 这种格式的uri
解析带有由 . 和 .. 组成的相对路径，解析成绝对路径
如果 merge_slashes 指令没有被关闭（默认是开启），则自动将两个相邻的斜杠合并成一个斜杠（ //test –> /test ）

一个location可以是前缀匹配字符串，也可以是正则表达式。正则表达式由 ~* 和 ~ 修饰，前者不匹配大小写，后者匹配大小写。为请求找到一个匹配的location，nginx首先会检查所有的前缀匹配字符串，被最大长度匹配到的location将会被选中和保存。接下来会检查正则表达式location，按照它们出现在配置文件中的顺序依次检查，直到匹配到第一个满足条件的location，结束检查。如果一个都没有匹配上，那么上一个被保存的location会被使用。
location块可以嵌套。
如果一个最长前缀匹配字符串拥有 ^~ 修饰符，则正则表达式不会被检查，同样地， = 修饰符被用来做精确匹配。如果一个location被精确匹配到了，则结束匹配。比如说，如果 “/“ 这个请求经常发生，那么定义一个 ”location = /“ 可以加快处理请求的速度。

针对上面的语法，我们来举几个例子：

location = / {
    [ configuration A ]
}

location / {
    [ configuration B ]
}

location /documents/ {
    [ configuration C ]
}

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

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

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

一个带有@前缀的location，不是用来做普通的请求处理的，而是用来做重定向。他们不能嵌套，不能包含嵌套的location块。

如果一个location由一个斜杠结尾，那么这个请求会被以下其中一个程序处理： proxy_pass, fastcgi_pass, uwsgi_pass, scgi_pass, memcached_pass, grpc_pass。如果一个URI匹配上了这个location，但是末尾没有斜杠，那么一个永久重定向（301）会被返回，重定向的地址就是原URI再加一个斜杠。如果这不是你所期望的，你可以这样：

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

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