location官方文档：http://nginx.org/en/docs/http/ngx_http_core_module.html#location
Syntax: location [ = | ~ | ~* | ^~ ] uri { ... }
location @name { ... }
Default: —
Context: server, location
这个配置的设置依赖于请求的URL。
对规范化的URL进行匹配,文本解码后使用"%xx"的格式进行编码,解析由.和..组成的相对路径,并且可能压缩两个或2个以上的斜杠到单一的斜杠。
location 可以被定义为一个前缀字符串,或者正则表达式.正则表达式使用~*(不区分大小写) 或 ~(区分大小写)被指定.
去查找location,匹配给到的请求.
nginx首先去检查使用prefix strings(prefix location)定义的locations. </images/ 这种的属于prefix string>
接着长的prefix strings被匹配记忆.
接下来 正则表达式被检测,在配置文件中的顺序去匹配
当搜索到第一个被匹配的正则表达式,将停止搜索,并且相应的配置项被应用
如果没有正则表达式被匹配到,更早的被查找到的prefix location被使用.
location 块是可以嵌套的,除了一下例外的情况:
不区分大小写的操作系统像 Mac Os x 和cygwin,忽略了与prfix strings的匹配.可是比较限于1字节的语言环境(comparison is limited to one-byte locales)<翻译不是很准确>
正则表达式可以包含捕获,稍后用于其他指令
如果最长前缀匹配位置有"^~"修饰符那么不进行正则匹配.
同样,使用"="修饰符,有可能定义一个URL和位置的精确匹配,如果精确匹配被发现,那么匹配结束.例如:如果"/"请求经常发生,定义了一个"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/documents.html" 匹配 C
"/images/" 匹配 D
"/images/1.jpd" 匹配 E
"@"前缀自定义了个location字符串.这样的一个location不用于常规请求的处理,但是用于请求的重定向.他不能被嵌套,也不能包含嵌套location
如果一个location被定义为前缀字符串,结束符是个斜线"/",并且请求由proxy_pass, fastcgi_pass, uwsgi_pass, scgi_pass, or memcached_pass他们中的一个来处理,那么进行特殊的处理.响应请求URI等于这个字符串,但是不包含最后的"/",代码301永久重定向将被返回给请求添加斜线的URL.如果这不是你所希望的,一个URL精确的匹配和location被这样定义:
location /user/ {
proxy_pass http://user.example.com;
}
location = /user {
proxy_pass http://login.example.com;
}