討論nginx location 順序問題

2022-05-28 18:02:14

在很長的一段時間裡，我對上述的結論也一直深信不疑，甚至還將這個結論分享給其他小夥伴，直到在有一次設定時發現，請求 uri 明明是符合了字首匹配 ^~ 規則，但 nginx 卻沒有使用，這讓我對上述結論產生了疑惑。後續通過調研、實踐後發現，上述結論可以說對，但也不對，是不是更疑惑了？沒關係，看完這篇文章你就知道我為什麼會這樣說了。

本篇文章會從以下五個方面來介紹 location 順序問題

location 是什麼
location 的選項有哪些
location 的匹配規則是什麼
location 的應用規則是什麼
總結

話不多說，我們直接進入正題。

一、location 是什麼

location 翻譯成中文就是定位，已經描述的比較清晰了，因為它的作用就是根據請求 uri 定位到某一個規則塊，然後在由該規則塊決定怎麼處理使用者的請求。

location 模組看起來挺簡單的，但真要自己寫，有時候就會覺得無從下手，我應該用 location /images 、 location ^~ /images 還是 location ~ /images 呢？我應該幫這個location 規則放在什麼位置呢？將規則放在最前面會影響已有的設定嗎？....上面說的問題，相信大部分同學都遇到過，想要徹底解決，就必須要了解 location 的處理邏輯，當然這也是本篇文章的目的所在。

二、location 的選項有哪些？

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

按照匹配模式進行區分，location 後可以放置兩種型別的匹配規則，分別是字首字串（prefix string）和正規表示式（regular expression）。其中字首字串包括 =、^~ 以及不設定（也就是空串），而正規表示式只有 ~ 和 ~*。（這五種選項是經常看到的，還有一種不常用的 location @name { ... } ，並不在今天的討論範圍）

三、location 的匹配規則

只有請求 uri 滿足 location 的規則，才有可能被應用，而對於不同的匹配模式，location 的匹配規則也是不同的

字首字串

顧名思義，它表示從請求 uri 的開頭開始進行匹配，如果用 JavaScript 來描述的話，當 uri.indexOf(locationRule.uri) === 0 時表示滿足匹配規則，其中 uri 表示請求路徑，而 locationRule.uri 表示 location 設定的規則。

其中 = 選項比較特殊，它又叫做精準匹配，只有匹配規則與請求 uri 完全相等時才表示滿足條件，即只有當 uri === locationRule.uri 時才表示匹配成功。

正規表示式

其實就是通過正則匹配來驗證是否滿足規則，nginx 使用的是 Perl 相容正規表示式 (PCRE)，網上可以找到很多驗證正規表示式的站點，這裡就不再展開了。但要注意，為了方便設定，nginx 進行了一些非標準的優化，例如，不必像在標準正規表示式中那樣跳脫 URL 中的正斜槓(/)等等。

而對於 ~ 和 ~* 唯一的區別就是：~ 區分大小寫，而 ~* 不區分大小寫。

總結

下面，我們對 location 的選項進行一個簡單的總結

選項	匹配規則	範例
=	精準匹配	`location = /test {...}`
^~	從請求 uri 的開頭進行匹配	`location ^~ /test {...}`
[空串]	從請求 uri 的開頭進行匹配	`location /test {...}`
~	區分大小寫的正則匹配	`location ~ /test {...}`
~*	不區分大小寫的正則匹配	`location ~* /test {...}`

四、location 的應用規則

理論篇

在瞭解完匹配規則後，我們來看下 nginx 是如何應用這些規則的，這就要說到 location 的順序問題了。

下面是根據實踐以檔案總結出來的 location 應用規則的邏輯：

將 server 塊中的 location 按照匹配模式分成兩個列表，分別為字首字串規則列表和正則匹配規則列表。
首先遍歷字首字串規則列表，當滿足匹配的規則是精準匹配時（即匹配選項是 =），直接應用該規則，結束流程；否則找到匹配規則最長的那條記錄（記作 maxLenthStringPrefixRule），繼續執行邏輯3；
如果 maxLenthStringPrefixRule 存在且匹配選項是 ^~ ，應用該規則，結束流程；否則，執行邏輯4；
遍歷正則匹配規則列表，如果滿足匹配規則，則直接應用，流程結束；如果直到迴圈結束後依然沒有滿足規則的 location，則執行邏輯5；
如果 maxLenthStringPrefixRule 存在，則應用該規則，流程結束；如果沒有則返回 404，同樣結束流程。

如果上述描述看著很難理解，可以嘗試看下面的虛擬碼。

// 字串匹配的規則集合，按照在 .conf 檔案中的順序放置到該集合中
const stringPrefixRuleList = [...]
// 正則匹配的規則集合，按照在 .conf 檔案中的順序放置到該集合中
const regularExpressionRuleList = [...]
// 用於存放最長字串匹配的規則
let maxLenthStringPrefixRule;
// 遍歷字串匹配的規則集合
for (let stringPrefixRule of stringPrefixRuleList) {
    // 符合匹配規則
    if (stringPrefixRule.isMatched()) {
        // 匹配選項是精準匹配
        if (stringPrefixRule.option === '=') {
            // 應用該規則，結束流程
            applyRule(stringPrefixRule);
            return;
        }
        // 將最長匹配規則記錄下來，留到後面使用
        if (!maxLenthStringPrefixRule 
            || stringPrefixRule.uri.length > maxLenthStringPrefixRule.uri.length) {
            maxLenthStringPrefixRule = stringPrefixRule
        }
    }
}
// 如果最長匹配規則的選項是 ^~, 則應用該規則，流程結束
if (maxLenthStringPrefixRule && maxLenthStringPrefixRule.option === '^~') {
    applyRule(maxLenthStringPrefixRule);
    return;
}
// 遍歷正則匹配規則集合
for (let regularExpressionRule of regularExpressionRuleList) {
    // 如果有規則匹配上，則直接應用，流程結束
    if (regularExpressionRule.isMatched()) {
        applyRule(regularExpressionRule);
        return;
    }
}
// 如果最長字串匹配的規則存在，則應用該規則
if (maxLenthStringPrefixRule) {
    applyRule(maxLenthStringPrefixRule);
    return;
}
// 404，規則未找到
throw new Error(404)

由此，我們可以得到幾個結論：

命中 = 匹配規則後會終止搜尋，並直接使用該規則。所以，如果某個請求 url 頻繁發生，例如 /，我們可以在 nginx.conf 中新增 location = / 規則，這會加速這些請求的處理速度，因為在命中規則後會終止搜尋。
^~ 和空串的字首匹配，區別在於，如果命中 ^~ 的規則，並且是最長字首匹配，就會終止搜尋正則匹配規則列表。
除了命中精準匹配外，字首字串匹配列表都會被遍歷一遍，並且找到最長匹配的那條 location 規則，所以字首字串匹配和在檔案中的位置無關，但是和匹配長度有關。
由於正則匹配的時間、資源消耗較多，所以 nginx 在對 location 規則進行正則匹配時，命中一個就直接使用了，所以正則匹配和 location 規則在檔案中的位置有關

實踐篇

從上面的理論篇中，大家應該能大致瞭解到 nginx 是如何命中 location 規則的，為了加深大家記憶，同時也為了能佐證理論是對的，我們來一些實踐吧。

我們的模板是這樣的，後面所有的實踐內容，都是放到兩個 rule section 之間。

server {
    listen	9001;
    location / {
        default_type text/html;
        return 200 'hello world';
    }
    # ===== rule section ======
    # ===== rule section ======

精準匹配優先順序最高

location /test {
    default_type text/html;
    return 200 '/test';
}

location ~ /test {
   default_type text/html;
   return 200 '~ /test';
}

location = /test {
   default_type text/html;
   return 200 '= /test';
}

我們在 nginx.conf 放置了 /test、~ /test、= /test 三個 location 規則，隨後在瀏覽器輸入 localhost:9001/test，發現輸出內容是 = /test，符合我們的預期，= 選項的優先順序最高。

正則匹配和順序有關

location ~ /test {
   default_type text/html;
   return 200 '~ /test';
}

location ~ /test/*/demo {
   default_type text/html;
   return 200 '~ /test/*/demo';
}

隨後我們將 rule section 區塊替換成 ~ /test 和 ~ /test/*/demo 規則，在瀏覽器輸入 localhost:9001/test/xyz/demo，從正則角度來說，/test/xyz/demo 既滿足 /test規則，又滿足 /test/*/demo 規則，但是由於 ~ /test 在檔案中位置靠前，所以優先被命中，理論上應該會輸出 ~ /test，校驗後發現，確實是這樣。

正則、^~字首匹配、空字首匹配混搭

location ^~ /test {
   default_type text/html;
   return 200 '^~ /test';
}
location /test/more/andmore {
   default_type text/html;
   return 200 '/test/more/andmore';
}
location ~ /test {
   default_type text/html;
   return 200 '~ /test';
}

將 section rule 區域替換成上述內容，然後在瀏覽器中輸入 localhost:9001/test/more/andmore，猜猜會發生什麼？

我們來一起分析下：