Nginx Location 匹配規則最佳實踐

2024-05-27碼農

戳下方名片，關註並 星標！

回復「 1024 」獲取 2TB 學習資源！

👉 體系化學習：

— 特色專欄 —

/ /

大家好，我是民工哥！

Nginx 是開源、高效能、高可靠的 Web 和反向代理伺服器，支持熱部署，幾乎可以做到 7 * 24 小時不間斷執行，還可在不間斷服務的情況下對軟體版本進行熱更新。Nginx 效能非常牛逼，占用記憶體少、並行能力強、能支持高並行，支持絕大部份協定，如TCP、UDP、SMTP、HTTPS等。最重要的是， Nginx 是免費開源的且可以商業化，配置使用也比較簡單。

在中國有眾多互聯網大廠，如百度、京東、新浪、網易、騰訊等都在使用 Nginx，也有很多高知名度的國外網站也在使用 Nginx，比如：Netflix、GitHub、SoundCloud、MaxCDN等。

官方網站：http://www.nginx.org

在學習 Nginx 技術棧的路上，有一個非常重要的知識點： nginx location匹配規則 ！

Nginx的location匹配順序是Nginx配置中非常核心且重要的概念，它決定了Nginx如何處理進入伺服器的請求。理解location匹配順序不僅有助於最佳化Nginx的效能，還能確保網站或套用的正確執行。下面將詳細闡述Nginx的location匹配順序，並透過例項加以說明。

Nginx location匹配順序詳解

精確匹配 (=)

當請求的URI與location後的字串完全相同時，Nginx會選擇這個location塊進行處理。這種匹配方式的優先級最高。例如：

location = /favicon.ico { # 處理favicon.ico的請求 }

只有當請求URI嚴格為/favicon.ico時，上述location塊才會被使用。

最長字串匹配 (無修飾詞)

當請求的URI以某個location後的字串開頭，並且這個字串是最長的，Nginx會選擇這個location塊。這種匹配方式根據字首的字元數量來確定優先級，字元數越多優先級越高。例如：

location /images/ { # 處理以/images/開頭的請求 }

location /images/jpg/ { # 處理以/images/jpg/開頭的請求 }

對於請求/images/jpg/photo.jpg，第二個location塊將被匹配，因為它有更長的匹配字首。

正規表式匹配 (~ 和 ~*)

正規表式匹配允許定義更復雜的URI匹配模式。 ~ 表示區分大小寫的正則匹配，而 ~* 表示不區分大小寫的正則匹配。Nginx會按照配置檔中的順序逐個檢查正規表式location塊，直到找到第一個匹配的塊。因此，正規表式的順序很重要。例如：

location ~ \.(gif|jpg|png)$ { # 處理以.gif、.jpg或.png結尾的請求（區分大小寫） }

location ~* \.(GIF|JPG|PNG)$ { # 處理以.GIF、.JPG或.PNG結尾的請求（不區分大小寫） }

在實際套用中，通常會將正規表式location塊放在配置檔的較後位置，以避免不必要的正則匹配開銷。

字首匹配 (^~)

如果請求的URI以某個字串開頭，並且這個字串後面緊跟的不是/或任何字元，Nginx會選擇匹配這個字首的location塊。這種匹配方式在找到精確匹配之前進行，但優先級低於精確匹配。例如：

location ^~ /static/ { # 處理以/static/開頭的請求（但不包括子目錄） }

對於請求/static/file.txt，上述location塊將被匹配；但對於請求/static/subdir/file.txt，則不會匹配（除非沒有其他更長的字首匹配）。

然而，這個描述可能有些誤導，因為實際上 ^~ 修飾詞的行為更接近於「最長字串匹配」的特殊情況，它在找到任何正規表式位置塊之前匹配最長的字首。如果找到了與 ^~ 修飾的location匹配的字首，Nginx將立即停止搜尋並使用這個location，即使可能存在更長的匹配。因此，將 ^~ 放在這裏描述可能是不準確的，它實際上應該在「最長字串匹配」之前進行考慮。但請註意，不同版本的Nginx可能會有細微的行為差異，因此建議查閱具體版本的官方文件以獲取最準確的資訊。