一、語法規則：

• = 開頭表示精確匹配

• ^~ 開頭表示uri以某個常規字符串開頭，理解為匹配url路徑即可(非正則)

• ~ 開頭表示區分大小寫的正則匹配

• ~* 開頭表示不區分大小寫的正則匹配

• !~和!~*分別為區分大小寫不匹配及不區分大小寫不匹配的正則

• / 通用匹配，任何請求都會匹配到

優先級：

• 等號類型（=）的優先級最高。一旦匹配成功，則不再查找其他location的匹配項

• ^~和通用匹配。使用前綴匹配，不支持正則表達式，如果有多個location匹配成功的話，不會終止匹配過程，會匹配表達式最長的那個(下方有例子)

• 如果上一步得到的最長的location為^~類型，則表示阻斷正則表達式，不再匹配正則表達式

• 如果上一步得到的最長的location不是^~類型，繼續匹配正則表達式，只要有一個正則成功，則使用這個正則的location，立即返回結果，并結束解析過程

二、驗證：

1、精確匹配：

在conf.d文件夾下創建配置文件test.com.conf，內容如下：

上圖中第一個和第二個location匹配條件一樣，都是/test.html，但第二個為精準匹配到靜態路徑，因此第一個不會執行，會執行第二個，www.test.com為本地域名解析，access_log和error_lor可以單獨為每個模塊定義日志

通過域名和路徑訪問后的內容如下：

注意：路徑/usr/share/nginx/test_html文件夾下需要有test.html才可以正常訪問

上圖中指定靜態資源路徑用的關鍵字root，還可以用alias，那么root和alias的區別是什么？

• 用root屬性指定的值是要加入到最終路徑中的，匹配條件會拼接到路徑中

• 用alias屬性指定的值不需要加入到最終路徑中

如上圖中所示，請求的條件為test.html，通過root指定的路徑為/usr/share/nginx/test_html，因此在匹配的時候，這個路徑下就必須要有test.html這個文件才可以，否則就會找不到而報錯，如果用alias，那么通過瀏覽器進行請求的時候，alias也是指定到/usr/share/nginx/test_htm路徑下，但是會匹配默認的index.html，而無須強制匹配test.html，但是此時就不能使用”=”來進行精確匹配，現在將root改為alias,如圖：

注意：alias指定的路徑結尾要加”/”

下面的配置文件采用roo指定路徑，當通過域名請求http://www.test.com/html/的時候，將跳轉到/usr/share/nginx/html/下的index.html頁面，如圖：

下面的配置文件采用alias指定路徑，請求http://www.test.com/linshi/的時候，將跳轉到/usr/share/nginx/test_html/index.html頁面，如圖：

2、通過^~方式實現匹配：

例如：下面配置文件有兩條規則，分別匹配url以字母a開頭，但是長度不同，首先將長的規則先注釋掉，如圖：

通過curl請求查看狀態碼，如圖：

說明：當前只有一個規則開啟，因此當匹配url以/a/開頭的任何url時，都會返回狀態碼666

現在將第二條規則注釋取消，打開規則，如圖：

再次發起同樣的請求，觀察返回狀態碼，如圖：

從上圖可以看出，兩條規則同時被匹配成功，但是第二條規則比較長，因此第二條規則優先被匹配，如果^~匹配成功了，那么表示阻斷正則表達式，不再進行正則匹配

3、通過”~”方式實現匹配：

上圖中的匹配規則都是通過”^~”方式來實現的，那么在匹配最長規則的時候又分為兩種情況：

• 第一種：最長規則通過^~來實現匹配(上圖中的最長規則就是通過^~實現)

• 第二種：最長的規則不是通過^~實現匹配，而是通過普通匹配來實現

當最長規則是通過普通匹配的時候，將會繼續正則匹配， 只要有一個正則成功，則使用這個正則的location，停止繼續匹配，返回結果

現在將第二條規則改為普通匹配，并添加一條正則匹配，如圖：

再次執行同樣的請求命令，得到的狀態碼如下：

說明：從上圖可以看出請求/a/b/的時候，首先會到達第二條規則(最長規則)，由于第二條規則為普通匹配(不是^~匹配)，因此會繼續去匹配正則，也就是第三條規則，因此最終返回狀態碼為888

4、通過"~*"方式實現匹配:

” ~* ” 表示不區分大小寫的正則匹配

例如：通過url請求/a/b/或者/A/B/，查看返回狀態碼，如圖：

請求結果如下：

從上圖可以看出，無論匹配的是大寫還是小寫，都會返回對應狀態碼888

常用方法還有匹配圖片后綴，并返回指定信息，如圖：

5、”!~*” 和”!~” 不常用，再次不做介紹

6、通過”/” 實現通用匹配：

本例子中，9091服務為httpd

第一種情況：proxy_pass最后面沒有斜杠,匹配路徑有斜杠(/bbb/)，如圖：

說明：proxy_pass最后面沒有斜杠”/”，此時通過瀏覽器請求http://10.9.2.248/bbb/，那么實際訪問的地址就是 http://10.9.2.248:9091/bbb/，會將匹配路徑/bbb一起加過去

此時如果在http的目錄頁面目錄htdocs中創建目錄bbb，在bbb目錄下創建文件index.html，然后即可實現正常訪問，如圖：

第二種情況： proxy_pass最后面有斜杠 “/”，匹配路徑也有斜杠(/bbb/)，如圖：

說明：proxy_pass最后面有斜杠”/”，此時通過瀏覽器請求http://10.9.2.248/bbb/，那么實際訪問的地址就是 http://10.9.2.248:9091，會將/bbb拋棄的，如圖：

第三種情況：proxy_pass后面還有其他路徑但是最后沒有 “/”， 匹配路徑也有斜杠(/bbb/) ，如圖：

說明，此時通過瀏覽器訪問http://10.9.2.248/bbb/index.html，實際請求的是http://10.9.2.248/cxxindex.html(注意位置是默認路徑下，不是ccc路徑下，如果proxy_pass的路徑為/ccc/ddd，那么實際請求的就是ccc路徑下的cccindex.html)

在httpd的默認路徑下(htdocs)創建文件cxxindex.html，然后訪問，如圖：

第四種情況： proxy_pass后面還有其他路徑但是最后有 “/”， 匹配路徑也有斜杠(/bbb/) ，如圖：

說明：此時通過瀏覽器訪問：http://10.9.2.248/bbb/index.html，實際訪問的是http://10.9.2.248/ccc/index.html

在httpd默認路徑下(htdocs)創建一個名稱為ccc的文件夾，在內部定義一個index.html，然后訪問，如圖：

第五種情況：location匹配路徑末尾沒有 “/”，proxy_pass后面也沒有”/”，如圖：

說明：8081端口為httpd的服務器端口，如果匹配路徑和proxy_pass后都沒有”/”，那么此時訪問http://10.9.2.248/bbb，默認將請求到http://127.0.0.1:8081/bbb/index.html的內容，此時在httpd默認路徑htdocs下創建文件夾bbb，內部創建index.html，定義內容為：i am match bbb，通過IP請求如圖：

更多內容參考鏈接地址：https://www.ywdevops.cn/index.php/2021/11/08/nginx-5/

閱讀原文：原文鏈接