首頁 >web前端 >js教程 >Nginx的location匹配實例分享

Nginx的location匹配實例分享

小云云
小云云原創
2018-02-12 15:45:251835瀏覽

本文主要和大家分享Nginx的location匹配實例,由於團隊在進行前後端分離,前端接管了Nginx和node層,在日常的工作中,跟Nginx打交道的時候挺多的。之前對location的配對規則是一知半解的,為了搞清楚location是如何配對的,希望能幫助大家。

語法規則

location [ = | ~ | ~* | ^~ ] uri { ... }
location @name { ... }

語法規則很簡單,一個location關鍵字,後面跟著可選的修飾符,後面是要匹配的字符,花括號中是要執行的操作。

修飾符

  • = 表示精確比對。只有請求的url路徑與後面的字串完全相等時,才會命中。

  • ~ 表示該規則是使用正規定義的,區分大小寫。

  • ~* 表示該規則是使用正規定義的,不區分大小寫。

  • ^~ 表示如果符號後面的字元是最佳匹配,採用該規則,不再進行後續的查找。

符合過程

對請求的url序列化。例如,對%xx等字元進行解碼,去除url中多個相連的/,解析url中的...等。這一步是匹配的前置工作。

location有兩種表示法,一種是使用前綴字符,一種是使用正則。如果是正規的話,前面有~~*修飾符。

具體的匹配過程如下:

首先檢查使用前綴字元定義的location,選擇最長匹配的項目並記錄下來。

如果找到了精確匹配的location,也就是使用了=修飾符的location,結束查找,使用它的配置。

然後按順序查找使用正規定義的location,如果匹配則停止查找,使用它定義的配置。

如果沒有符合的正規location,則使用前面記錄的最長來匹配前綴字元location。

基於以上的匹配過程,我們可以得到以下兩點啟示:

  1. #使用正規定義的location在設定檔中出現的順序很重要。因為找到第一個匹配的正則後,查找就停止了,後面定義的正則就是再匹配也沒有機會了。

  2. 使用精確匹配可以提高查找的速度。例如經常請求/的話,可以使用=來定義location。

範例

接下來我們以一個例子來具體說明一下匹配過程。

假如我們有下面的一段設定檔:

location = / {
    [ configuration A ]
}

location / {
    [ configuration B ]
}

location /user/ {
    [ configuration C ]
}

location ^~ /images/ {
    [ configuration D ]
}

location ~* \.(gif|jpg|jpeg)$ {
    [ configuration E ]
}

請求/精準符合A,不再往下找。

請求/index.html匹配B。首先查找匹配的前綴字符,找到最長匹配是配置B,接著又按照順序查找匹配的正則。結果沒有找到,因此使用先前標記的最長匹配,即配置B。

請求/user/index.html匹配C。首先找到最長匹配C,由於後面沒有匹配的正則,所以使用最長匹配C。
請求/user/1.jpg匹配E。首先進行前綴字元的查找,找到最長匹配項C,繼續進行正規查找,找到匹配項E。因此使用E。

請求/images/1.jpg匹配D。首先進行前綴字元的查找,找到最長匹配D。但是,特殊的是它使用了^~修飾符,不再進行接下來的正規的匹配查找,因此使用D。這裡,如果沒有前面的修飾符,其實最終的匹配是E。大家可以想想為什麼。

請求/documents/about.html匹配B。因為B表示任何以/開頭的URL都會匹配。在上面的配置中,只有B能滿足,所以匹配B。

location @name的用法

@用來定義一個命名location。主要用於內部重定向,不能用來處理正常的請求。其用法如下:

location / {
    try_files $uri $uri/ @custom
}
location @custom {
    # ...do something
}

上例中,當嘗試存取url找不到對應的檔案就重定向到我們自訂的命名location(此處為custom)。

值得注意的是,命名location中不能再嵌套其它的命名location

URL尾部的/需不需要

關於URL尾部的/有三點也需要說明一下。第一點與location配置有關,其他兩點無關。

  1. location中的字元有沒有/都沒有影響。也就是說/user//user是一樣的。

  2. 如果URL結構是https://domain.com/的形式,尾部有沒有/都不會造成重定向。因為瀏覽器在發起請求的時候,預設加上了/。雖然很多瀏覽器在網址列也不會顯示/。這一點,可以訪問baidu驗證一下。

  3. 如果URL的結構是https://domain.com/some-dir/。尾部如果缺少/將導致重定向。因為根據約定,URL尾部的/表示目錄,沒有/表示檔案。所以造訪/some-dir/時,伺服器會自動去該目錄下找對應的預設檔。如果造訪/some-dir的話,伺服器會先去找some-dir文件,找不到的話會將some-dir當成目錄,重定向到/some-dir/,去該目錄下找預設檔。可以去測試一下你的網站是不是這樣的。

總結

location的配置有兩種形式,前綴字元和正規則。尋找符合的時候,先找前綴字符,選擇最長匹配項,再找正規則。正規的優先權高於前綴字元。

正規等查找是按照在設定檔中的順序進行的。因此正則等順序很重要,建議越精細的放的越靠前。

使用=精準匹配可以加快查找的順序,如果根網域經常被存取等話建議使用=

相關推薦:

Javascript刷新頁面方法及location.reload()用法介紹

完全掌握AngularJS中$location

php程式header location跳轉注意事項


#

以上是Nginx的location匹配實例分享的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述:
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn