location路由規則配置詳解
location路由匹配發生在HTTP請求處理的find-config配置查詢階段，主要功能是：根據請求的URI地址匹配location路由表示式，如果匹配成功，就執行location後面的上下文配置塊。
實戰案例說明
本節的配置例項處於原始碼工程的nginx-location-demo。conf配置檔案中。在執行本節的例項前，需要修改openresty-start。bat（或openresty-start。sh）指令碼中的PROJECT_CONF配置檔案變數的值，將其修改為nginx-location-demo。conf，然後重啟OpenRestry/Nginx。
location語法詳解
Nginx配置檔案中，location配置項的語法格式如下：
location ［=|~|~*|^~］ 模式字串 { 。。。}
按照匹配的符號不同，location路由匹配主要分成精準匹配、普通匹配、正則匹配、預設根路徑匹配。下面逐一進行介紹。
1.精準匹配
精準匹配的符號標記為“=”，下面是一個簡單的精準匹配location的例子。
#精準匹配 location = /lua { echo “hit location： =/Lua”；}
如果請求URI和精準匹配的模式字串/lua完全相同，那麼精準匹配透過。
在所有的匹配型別中，精準匹配的優先順序最高。
執行本文的配套案例，在同時存在多個/lua匹配模式location的情況下，在瀏覽器中給Nginx傳送
http：//localhost/lua
的請求地址，輸出的是精準匹配的結果，如圖7-12所示。
圖7-12 輸出精準匹配
2.普通匹配
普通匹配的符號標記為“^~”，下面是一個簡單的普通匹配location的例子。
location ^~ /lua { echo “hit location： ^~ /lua”； }
普通匹配屬於字串字首匹配，詳細來說：如果請求路徑URI頭部匹配到location的模式字串，那麼匹配成功。如果匹配到多個字首，那麼最長模式匹配優先。
本文配套例項中配置了以下兩個普通匹配型別的location，具體配置如下：
#普通匹配一location ^~ /lua { echo “普通匹配： ^~ /lua”；}#普通匹配二，長一點location ^~ /lua/long { echo “普通匹配： ^~ /lua/long”；}
在瀏覽器中給Nginx傳送
http：//localhost/lua/long/path
的請求地址，輸出了普通匹配location的結果，如圖7-13所示。
圖7-13 輸出普通匹配
注意
普通匹配是字首匹配，也是Nginx預設的匹配型別。也就是說，型別符號“^~”可以省略，如果location沒有任何匹配型別，就為普通的字首匹配。如果一個URI命中多個location普通匹配，則最長的location普通匹配獲勝。
為了對以上結論進行論證，這裡舉一個例子，在配置檔案中配置兩個同樣字串模式的location，一個不帶型別符號，一個帶“^~”符號，具體如下：
#不帶型別符號，預設為普通匹配location /demo { echo “hit location： /demo ”；}#帶“^~”符號，普通匹配location ^~ /demo { echo “hit location： ^~ /demo”；}
執行重啟Nginx的指令碼openresty-restart。bat，發現Nginx不能啟動，檢視error。log錯誤日誌，報錯資訊如下：
。。。 17：33：39 ［emerg］ 18760#25944： duplicate location “/demo” in 。。。/nginx-location-demo。conf：115
從錯誤資訊可以看出，在配置檔案中有兩個重複的location配置。
3.正則匹配
正則匹配的型別按照型別符號的不同可以細分為以下4種：
（1）~：標準正則匹配，區分字母大小寫，進行正則表示式測試，若測試成功，則匹配成功。
（2）~*：標準正則匹配，不區分字母大小寫，進行正則表示式測試，若測試成功，則匹配成功。
（3）！~：反向正則匹配，區分字母大小寫，進行正則表示式測試，若測試不成功，則匹配成功。
（4）！~*：反向正則匹配，不區分字母大小寫，進行正則表示式測試，若測試不成功，則匹配成功。下面是一個正則匹配的例子，可以匹配以hello。php或hello。asp結尾的URL請求。
#正則匹配 location ~*hello\。（asp|php）$ { echo “正則匹配： hello。（asp|php）$ ”； }
在瀏覽器中給Nginx傳送
http：//localhost/1/2/hellp。php
的請求地址，輸出的請求結果如圖7-14所示。
圖7-14 輸出的請求結果
如果配置檔案中存在多個正則匹配location，那麼它們之間的規則是順序優先的，只要匹配到第一個正則型別的location，就停止後面的正則型別的location測試。
例如，這裡有兩個正則匹配的location規則：\。（do|jsp）$和hello\。（do|jsp）$，具體如下：
#正則匹配型別location ~*\。（do|jsp）$ { echo “正則匹配： 。（do|jsp）$ ”； } #正則匹配型別 location ~*hello\。（do|jsp）$ { echo “正則匹配： hello。（do|jsp）$ ”；}
在瀏覽器中給Nginx傳送
http：//localhost/1/2/hellp。do
的請求地址，輸出的結果是由配置在前面的location輸出的，如圖7-15所示。
圖7-15 輸出結果
4.預設根路徑匹配
根路徑的路徑規則就是使用單個“/”符號，示例如下：
location / { echo “預設根路徑匹配： /”； }
透過瀏覽器隨便訪問一個地址，如
http：//localhost/foo
，使之不能匹配到其他的location，只能匹配到“/”根路徑，返回的結果如圖7-16所示。
圖7-16 返回的結果
表面看上去，location/{。。。}根路徑匹配非常類似普通匹配，但實際上該規則自成一類，雖然只有唯一的一個路徑，但是此類規則優先順序是最低的。
最後總結一下4種location之間的匹配次序，大致如下：
（1）型別之間的優先順序：精準匹配>普通匹配>正則匹配>“/”預設根路徑匹配。
（2）普通匹配同類型location之間的優先順序為最長字首優先。普通匹配的優先順序與location在配置檔案中所處的先後順序無關，而與匹配到的字首長度有關。
（3）正則匹配同類型location之間的優先順序為順序優先。只要匹配到第一個正則規則的location，就停止後面的正則規則的測試。正則匹配與location規則定義在配置檔案中的先後順序強相關。
常用的location路由配置
第一個應該配置的屬於“/”根路由規則。“/”根路由規則可以路由到一個靜態首頁：
location / { root html； index index。html index。htm；}
表示在請求URI匹配到“/”根路由規則時，首先Nginx會在html目錄下查詢index。html檔案，如果沒有找到，就查詢index。htm檔案，將找到的檔案內容返回給客戶端。
“/”根路由規則也可以路由到一個訪問很頻繁的上游服務，比如Spring Cloud微服務架構中的服務閘道器：
location / { proxy_pass http：//127。0。0。1：7799/ ；}
這裡的127。0。0。1：7799假定為Zuul閘道器的IP和埠，當請求匹配到“/”根路由規則時，將直接轉發給上游Zuul應用閘道器伺服器。
第二個應該配置的屬於靜態檔案路由規則。對靜態檔案請求進行響應，這是Nginx作為HTTP伺服器的強項。靜態檔案匹配規則有兩種配置方式：目錄匹配（字首匹配）和字尾匹配（正則匹配），可以任選其一，也可以搭配使用。
目錄匹配（字首匹配）配置例項如下：
root /www/resources/static/； #字首匹配location ^~ /static/ { root /www/resources/；}
所有匹配/static/。。。規則的靜態資源請求（如/static/img/1。png）都將路由到root指令所配置的檔案目錄/
www/resources/static/
下對應的某個檔案（如/
www/resources/static/img/1。png
）。
字尾匹配（正則匹配）配置例項如下：
location ~*\。（gif|jpg|jpeg|png|css|js|ico）${ root /www/resources/；}
所有匹配到以上正則規則的靜態資源請求（如/static/img/2。png）都將路由到root指令所配置的檔案目錄/
www/resources/static/
下對應的某個檔案（如/
www/resources/static/img/2。png
）。
本文給大家講解的內容是Nginx/OpenResty詳解，location路由規則配置詳解
下篇文章給大家講解的是 Nginx/OpenResty詳解，Nginx的rewrite模組指令；
覺得文章不錯的朋友可以轉發此文關注小編；
感謝大家的支援！
