nginx的配置指令的作用域可以分為 main，server，location這3個(gè)種，實(shí)際上這3者不是依次包含的關(guān)系，而是相互獨(dú)立的關(guān)系，比如一個(gè)只具有main級別作用域的指令，是不能寫在某個(gè)server或者location內(nèi)的，模塊的某個(gè)指令可以同時(shí)具有main，server，location這3種作用域，另外每個(gè)模塊有 main,srv,loc這3個(gè)級別的配置，一個(gè)模塊的main級別的配置對所有的server和location都是共享的，srv級別的配置對所有 location都是共享的，location只有自己獨(dú)立的loc級別的配置，這就是為什么一個(gè)模塊的srv和loc級別的配置需要merge，而 main級別的配置不需要merge的原因。這里看起來有點(diǎn)繞，區(qū)分一下main，server，location分別作為一種作用域級別和一個(gè)主體，類似于形容詞和名字的區(qū)別，nginx的配置關(guān)系還是不難理解的。

​一般來說一個(gè)請求url過來，nginx會(huì)將它解析到某一個(gè)location來處理。這個(gè)解析的過程實(shí)際上根據(jù)location的配置基本可以分為字符串匹配和正則表達(dá)式匹配這2種。對于location的組織方式，最簡單的就是直接將它們保存為一個(gè)鏈表，解析url的時(shí)候一個(gè)一個(gè)遍歷即可找到相應(yīng)location，但是這樣效率太低，對像nginx這種高性能的服務(wù)器來說是完全不可取的，nginx將字符串匹配的location組織成了一個(gè)三叉的字符串排序樹，而且建立的時(shí)候也考慮了樹的平衡性。文章后面我講詳細(xì)介紹源碼的實(shí)現(xiàn)。

​首先我來大概的介紹一下location的種類和匹配規(guī)則，以nginx wiki(http://wiki.nginx.org/HttpCoreModule#location)的例子做說明：

location 優(yōu)先級官方文檔

• Directives with the = prefix that match the query exactly. If found, searching stops.
• All remaining directives with conventional strings, longest match first. If this match used the ^~ prefix, searching stops.
• Regular expressions, in order of definition in the configuration file.
• If #3 yielded a match, that result is used. Else the match from #2 is used.

=前綴的指令嚴(yán)格匹配這個(gè)查詢。如果找到，停止搜索。

所有剩下的常規(guī)字符串，最長的匹配。如果這個(gè)匹配使用^〜前綴，搜索停止。

正則表達(dá)式，在配置文件中定義的順序。

如果第3條規(guī)則產(chǎn)生匹配的話，結(jié)果被使用。否則，如同從第2條規(guī)則被使用。

例如

location = / { 
 # 只匹配"/". 
 [ configuration A ]  
} 
location / { 
 # 匹配任何請求，因?yàn)樗姓埱蠖际且?/"開始 
 # 但是更長字符匹配或者正則表達(dá)式匹配會(huì)優(yōu)先匹配 
 [ configuration B ]  
} 
location ^~ /images/ { 
 # 匹配任何以 /images/ 開始的請求，并停止匹配 其它location 
 [ configuration C ]  
} 
location ~* \.(gif|jpg|jpeg)$ { 
 # 匹配以 gif, jpg, or jpeg結(jié)尾的請求.  
 # 但是所有 /images/ 目錄的請求將由 [Configuration C]處理.   
 [ configuration D ]  
} 

可以看到上面的例子中有5種不同類型的location，其中第4個(gè)帶 “~” 號(hào)前綴的為需要正則匹配的location，nginx在進(jìn)行url解析時(shí)對這5種不同類型的location具有不同的優(yōu)先級規(guī)則，大致的規(guī)則如下：

1，字符串精確匹配到一個(gè)帶 “=” 號(hào)前綴的location，則停止，且使用這個(gè)location的配置；

2，字符串匹配剩下的非正則和非特殊location，如果匹配到某個(gè)帶 "^~" 前綴的location，則停止；

3，正則匹配，匹配順序?yàn)閘ocation在配置文件中出現(xiàn)的順序。如果匹配到某個(gè)正則location，則停止，并使用這個(gè)location的配置；否則，使用步驟2中得到的具有最大字符串匹配的location配置。

​例如，對下面的請求有:

1， / -> 精確匹配到第1個(gè)location，匹配停止，使用configuration A

2，/some/other/url -> 首先前綴部分字符串匹配到了第2個(gè)location，然后進(jìn)行正則匹配，顯然沒有匹配上，則使用第2個(gè)location的配置configurationB

3，/images /1.jpg -> 首先前綴部分字符串匹配到了第2個(gè)location，但是接著對第3個(gè)location也前綴匹配上了，而且這時(shí)已經(jīng)是配置文件里面對這個(gè)url的最大字符串匹配了，并且location帶有 "^~" 前綴，則不再進(jìn)行正則匹配，最終使用configuration C

4，/some/other/path/to/1.jpg -> 首先前綴部分同樣字符串匹配到了第2個(gè)location，然后進(jìn)行正則匹配，這時(shí)正則匹配成功，則使用congifuration D

請求URI例子:

/ -> 符合configuration A
/documents/document.html -> 符合configuration B
/images/1.gif -> 符合configuration C
/documents/1.jpg ->符合 configuration D
@location 例子
error_page 404 = @fetch;

location @fetch(
proxy_pass http://fetch;
)

location匹配命令

• ~ #波浪線表示執(zhí)行一個(gè)正則匹配，區(qū)分大小寫
• ~* #表示執(zhí)行一個(gè)正則匹配，不區(qū)分大小寫
• ^~ #^~表示普通字符匹配，如果該選項(xiàng)匹配，只匹配該選項(xiàng)，不匹配別的選項(xiàng)，一般用來匹配目錄
• = #進(jìn)行普通字符精確匹配
• @ #"@" 定義一個(gè)命名的 location，使用在內(nèi)部定向時(shí)，例如 error_page, try_files

location 匹配的優(yōu)先級(與location在配置文件中的順序無關(guān))

= 精確匹配會(huì)第一個(gè)被處理。如果發(fā)現(xiàn)精確匹配，nginx停止搜索其他匹配。

普通字符匹配，正則表達(dá)式規(guī)則和長的塊規(guī)則將被優(yōu)先和查詢匹配，也就是說如果該項(xiàng)匹配還需去看有沒有正則表達(dá)式匹配和更長的匹配。

^~ 則只匹配該規(guī)則，nginx停止搜索其他匹配，否則nginx會(huì)繼續(xù)處理其他location指令。

最后匹配理帶有"~"和"~*"的指令，如果找到相應(yīng)的匹配，則nginx停止搜索其他匹配；當(dāng)沒有正則表達(dá)式或者沒有正則表達(dá)式被匹配的情況下，那么匹配程度最高的逐字匹配指令會(huì)被使用。

到此這篇關(guān)于nginx 配置location匹配規(guī)則實(shí)例講解的文章就介紹到這了,更多相關(guān)nginx 配置location匹配規(guī)則內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！