说明:
"="精准匹配案例
location = /login {
# 精确匹配 /login ,匹配成功后,立即结束
}
"~"区分大小写正则匹配案例
location ~ /images/ {
#正则匹配,区分大小写,匹配成功后,立即结束
}
”~*"不区分大小写正则匹配案例
location ~* /images/ {
#正则匹配,不区分大小写,匹配成功后,立即结束
}
"^~" 不进行正则匹配的标准匹配
location ^~ /images/ {
# 匹配任何以 /images/ 开头的地址,匹配符合以后,停止往下搜索正则,采用这一条。
}
普通匹配(最长字符匹配)
location /blog/ {
# 与location顺序无关
# 若完全匹配成功,就不在继续匹配,否则还会进行正则匹配
}
优先级
多个location配置的情况匹配顺序为
首先精确匹配 = ;
其次前缀匹配 ^~;
其次是按照配置文件中的正则匹配;
然后匹配不带任何修饰符的前缀匹配;
最后交给/通用匹配;
location是否以“/”结尾
在ngnix中location进行的是模糊匹配
1.没有“/”结尾时,location/abc/def可以匹配/abc/defghi请求,也可以匹配/abc/def/ghi等
2.而有“/”结尾时,location/abc/def/不能匹配/abc/defghi请求,只能匹配/abc/def/anything这样的请求
nginx转发时,会将原uri去除loc带/时ation匹配表达式 后的内容拼接在proxy_pass中url之后。
测试地址:http://www.web-jshtml.cn/productapi/getSms/
场景一:
location ^~ /productapi/ {
proxy_pass http://www.web-jshtml.cn/productapi/;
}
代理后实际访问地址:http://www.web-jshtml.cn/productapi/getSms/;
场景二:
location ^~ /productapi {
proxy_pass http://www.web-jshtml.cn/productapi//getSms/;
}
代理后实际访问地址:http://www.web-jshtml.cn/productapi//getSms/;
场景三:
location ^~ /productapi/ {
proxy_pass http://www.web-jshtml.cn/;
}
代理后实际访问地址:http://www.web-jshtml.cn/getSms/;
场景四:
location ^~ /productapi {
proxy_pass http://www.web-jshtml.cn/;
}
代理后实际访问地址:http://www.web-jshtml.cn//getSms/;
如url中不包含path,则直接将原uri拼接在proxy_pass中url之后;
如url中包含path,则将原uri去除location匹配表达式后的内容拼接在proxy_pass中的url之后。
测试地址:http://www.web-jshtml.cn/productapi/getSms/
场景一:
location ^~ /productapi/ {
proxy_pass http://www.web-jshtml.cn/productapi;
}
代理后实际访问地址:http://www.web-jshtml.cn/productapigetSms/;
场景二:
location ^~ /productapi {
proxy_pass http://www.web-jshtml.cn/productapi;
}
代理后实际访问地址:http://www.web-jshtml.cn/productapi/getSms/;
场景三:
location ^~ /productapi/ {
proxy_pass http://www.web-jshtml.cn;
}
代理后实际访问地址:http://www.web-jshtml.cn/productapi/getSms/;
场景四:
location ^~ /productapi {
proxy_pass http://www.web-jshtml.cn;
}
代理后实际访问地址:http://www.web-jshtml.cn/productapi/getSms/;