location匹配规则

说明:
"="精准匹配案例 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的proxy_pass
proxy_pass配置中url末尾
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/;
proxy_pass配置中url末尾不带/时
如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/;
浙公网安备 33010602011771号