nginx location

Nginx 的 location 实现了对请求的细分处理，有些 URI 返回静态内容，有些分发到后端服务器等，今天来彻底弄懂它的匹配规则
一个最简单的 location 的例子如下
server {   
 server_name website.com;   
 location /admin/ {
# The configuration you place here only applies to
}
}
location 支持的语法location [=|~|~*|^~|@] pattern { ... }，乍一看还挺复杂的，来逐个看一下。
location修饰符类型
「=」 修饰符：要求路径完全匹配
server {   
 server_name website.com;    
location = /abcd { 
   […]    
}
}
http://website.com/ABCD可能会匹配，也可以不匹配，取决于操作系统的文件系统是否大小写敏感（case-sensitive）。ps: Mac 默认是大小写不敏感的，git 使用会有大坑。
http://website.com/abcd?param1¶m2匹配，忽略 querystring
http://website.com/abcd/不匹配，带有结尾的/
 

「~」修饰符：区分大小写的正则匹配

 
server { 
   server_name website.com;   
 location ~ ^/abcd$ { 
   […]    
}
}
^/abcd$这个正则表达式表示字符串必须以/开始，以$结束，中间必须是abcd
http://website.com/abcd匹配（完全匹配）
http://website.com/ABCD不匹配，大小写敏感
http://website.com/abcd/不匹配，不能匹配正则表达式
http://website.com/abcde不匹配，不能匹配正则表达式
 

「~*」不区分大小写的正则匹配

 
server {   
 server_name website.com;  
  location ~* ^/abcd$ {  
  […]  
  }
}
http://website.com/abcd匹配(完全匹配)
http://website.com/ABCD匹配(大小写不敏感)
http://website.com/abcd/不匹配，不能匹配正则表达式
http://website.com/abcde不匹配，不能匹配正则表达式
##「^~」修饰符：前缀匹配
如果该 location 是最佳的匹配，那么对于匹配这个 location 的字符串， 该修饰符不再进行正则表达式检测。注意，这不是一个正则表达式匹配，它的目的是优先于正则表达式的匹配

查找的顺序及优先级

当有多条 location 规则时，nginx 有一套比较复杂的规则，优先级如下：
精确匹配=
前缀匹配^~（立刻停止后续的正则搜索）
按文件中顺序的正则匹配~或~*
匹配不带任何修饰的前缀匹配。
这个规则大体的思路是
先精确匹配，没有则查找带有^~的前缀匹配，没有则进行正则匹配，最后才返回前缀匹配的结果（如果有的话）
如果上述规则不好理解，可以看下面的伪代码（非常重要）
function match(uri): 
 rv = NULL
if uri in exact_match:
return  exact_match[uri]
if uri in prefix_match:
if prefix_match[uri] is'^~':
return prefix_match[uri]else:  
    rv = prefix_match[uri]
 // 注意这里没有return，且这里是最长匹配
if uri in regex_match:
return  regex_match[uri]
// 按文件中顺序，找到即返回returnrv复制代码
一个简化过的Node.js写的代码如下
function ngx_http_core_find_location(uri, static_locations, regex_locations, named_locations, track){letrc =null;
letl = ngx_http_find_static_location(uri, static_locations, track);
if(l) {
if(l.exact_match) {
returnl;    
}
if(l.noregex) {returnl;   
 }   
 rc = l;  
}
if(regex_locations) {
for(leti =0; i < regex_locations.length; i ++) {
if(track) track(regex_locations[i].id);
letn =null;
if(regex_locations[i].rcaseless) {       
 n = uri.match(newRegExp(regex_locations[i].name));    
  }else{    
    n = uri.match(newRegExp(regex_locations[i].name),"i");     
 }
if(n) {returnregex_locations[i];    
  }   
 } 
 }
returnrc;
}
 
案例分析
案例 1
server {    
server_name website.com;   
 location /doc {
return701;
# 用这样的方式，可以方便的知道请求到了哪里
}    
location ~* ^/document$ {
return702;
# 用这样的方式，可以方便的知道请求到了哪里
}
}
按照上述的规则，第二个会有更高的优先级
案例2
server {   
 server_name website.com;  
  location /document {
return701;    
}   
 location ~* ^/document$ {
return702;    
}
}
第二个匹配了正则表达式，优先级高于第一个普通前缀匹配
案例 3
server {   
server_name website.com;   
 location ^~ /doc {
return701;  
  }  
  location ~* ^/document$ {
return702;    }
}
第一个前缀匹配^~命中以后不会再搜寻正则匹配，所以会第一个命中
案例 4
server {    
server_name website.com;    
location /docu {
return701;  
  }   
 location /doc {
return702;    
}
}
curl -I website.com:8080/document返回HTTP/1.1 701，
server {    server_name website.com;    location /doc {return702;    }    location /docu {return701;    }}
curl -I website.com:8080/document依然返回HTTP/1.1 701
前缀匹配下，返回最长匹配的 location，与 location 所在位置顺序无关
案例 5
server {
listen 8080;
server_name website.com;   
 location ~ ^/doc[a-z]+ {return701;  
  } 
   location ~ ^/docu[a-z]+ {return702;    }
}
curl -I website.com:8080/document返回HTTP/1.1 701
把顺序换一下
server {
listen 8080;
server_name website.com;  
  location ~ ^/docu[a-z]+ {
return702;    }        location ~ ^/doc[a-z]+ {return701;    }
}
curl -I website.com:8080/document返回HTTP/1.1 702
 
 
作者：周佳琪周佳琪
 
posted @ 2020-07-27 09:03  依哈  阅读(202)  评论(0)  编辑  收藏  举报