Nginx处理Http请求11个阶段之find_config，彻底搞明白匹配规则

当我们在server快下的rewrite阶段执行完毕后，

开始根据请求的URL 去匹配相应的location进行处理 这个阶段就是find_config 阶段。

merge/slashes 可以合并2个 ‘/’

location匹配规则可以分这么几类:

前缀字符串:

• 常规的，
• =:精准匹配，
• ^~:正则匹配上后则不再进行正则匹配

正则表达式：

• ~：大小写敏感的正则匹配
• ~*:忽略大小写的正则匹配

用于内部跳转的命名location：

• @

localcation匹配顺序：

先对所有的location做一次匹配,这一步和我们在.conf文件里 写的location的顺序 实际上是无关的。这里有一颗二叉树放置了匹配的前缀。

这里分3种情况：

• =完全匹配上后，则停止做匹配了。也就是说=的优先级是最高的。
• ^~ 不用进行后面的匹配了。如果有多个，那么使用最长匹配。
• 如果都没有，则记住最长前缀匹配。

此时按.conf中的顺序挨个匹配location

如果匹配上了就使用匹配上的正则表达式。

如果所有正则都不匹配，就使用最长匹配的前缀字符串。

也就是说按照匹配优先级是 正则匹配>前缀匹配的。

下面举个例子：

以下URL会返回什么内容呢？

/Test1 
/Test1/ 
/Test1/Test2 

location ~ /Test1/$ { 
  return 200 'first regular expressions match!\n'; 
} 

location ~* /Test1/(\w+)$ { 
	return 200 'longest regular expressions match!\n'; 
} 
location ^~ /Test1/ { 
	return 200 'stop regular expressions match!\n'; 
} 
location /Test1/Test2 { 
  return 200 'longest prefix string match!\n'; 
} 
location = /Test1 { 
	return 200 'exact match!\n'; 
}

当我们进行以下请求的时候

1. /Test1 会匹配上最后一个location,返回 'exact match!'

2. /Test1/ 会匹配上^~ /Test1/,返回 'stop regular expressions match!'

3. /Test1/Test2 会返回什么呢？

大家思考一下， 欢迎在评论区留言。