網(wǎng)上有很多討論 nginx location 順序的話(huà)題，得到的結(jié)論也基本一致，總結(jié)為：

• 精準(zhǔn)匹配 =
• 前綴匹配 ^~
• 正則匹配 ~、~*
• 不帶修飾符的前綴匹配

在很長(zhǎng)的一段時(shí)間里，我對(duì)上述的結(jié)論也一直深信不疑，甚至還將這個(gè)結(jié)論分享給其他小伙伴，直到在有一次配置時(shí)發(fā)現(xiàn)，請(qǐng)求 uri 明明是符合了前綴匹配 ^~ 規(guī)則，但 nginx 卻沒(méi)有使用，這讓我對(duì)上述結(jié)論產(chǎn)生了疑惑。后續(xù)通過(guò)調(diào)研、實(shí)踐后發(fā)現(xiàn)，上述結(jié)論可以說(shuō)對(duì)，但也不對(duì)，是不是更疑惑了？沒(méi)關(guān)系，看完這篇文章你就知道我為什么會(huì)這樣說(shuō)了。

本篇文章會(huì)從以下五個(gè)方面來(lái)介紹 location 順序問(wèn)題

• location 是什么
• location 的選項(xiàng)有哪些
• location 的匹配規(guī)則是什么
• location 的應(yīng)用規(guī)則是什么
• 總結(jié)

話(huà)不多說(shuō)，我們直接進(jìn)入正題。

一、location 是什么

location 翻譯成中文就是定位，已經(jīng)描述的比較清晰了，因?yàn)樗淖饔镁褪歉鶕?jù)請(qǐng)求 uri 定位到某一個(gè)規(guī)則塊，然后在由該規(guī)則塊決定怎么處理用戶(hù)的請(qǐng)求。

location 模塊看起來(lái)挺簡(jiǎn)單的，但真要自己寫(xiě)，有時(shí)候就會(huì)覺(jué)得無(wú)從下手，我應(yīng)該用 location /images 、 location ^~ /images 還是 location ~ /images 呢？我應(yīng)該幫這個(gè)location 規(guī)則放在什么位置呢？將規(guī)則放在最前面會(huì)影響已有的配置嗎？....上面說(shuō)的問(wèn)題，相信大部分同學(xué)都遇到過(guò)，想要徹底解決，就必須要了解 location 的處理邏輯，當(dāng)然這也是本篇文章的目的所在。

二、location 的選項(xiàng)有哪些？

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

按照匹配模式進(jìn)行區(qū)分，location 后可以放置兩種類(lèi)型的匹配規(guī)則，分別是前綴字符串（prefix string）和正則表達(dá)式（regular expression）。其中前綴字符串包括 =、^~ 以及不設(shè)置（也就是空串），而正則表達(dá)式只有 ~ 和 ~*。（這五種選項(xiàng)是經(jīng)?？吹降?，還有一種不常用的 location @name { ... } ，并不在今天的討論范圍）

三、location 的匹配規(guī)則

只有請(qǐng)求 uri 滿(mǎn)足 location 的規(guī)則，才有可能被應(yīng)用，而對(duì)于不同的匹配模式，location 的匹配規(guī)則也是不同的

前綴字符串

顧名思義，它表示從請(qǐng)求 uri 的開(kāi)頭開(kāi)始進(jìn)行匹配，如果用 JavaScript 來(lái)描述的話(huà)，當(dāng) uri.indexOf(locationRule.uri) === 0 時(shí)表示滿(mǎn)足匹配規(guī)則，其中 uri 表示請(qǐng)求路徑，而 locationRule.uri 表示 location 設(shè)置的規(guī)則。

其中 = 選項(xiàng)比較特殊，它又叫做精準(zhǔn)匹配，只有匹配規(guī)則與請(qǐng)求 uri 完全相等時(shí)才表示滿(mǎn)足條件，即只有當(dāng) uri === locationRule.uri 時(shí)才表示匹配成功。

正則表達(dá)式

其實(shí)就是通過(guò)正則匹配來(lái)驗(yàn)證是否滿(mǎn)足規(guī)則，nginx 使用的是 Perl 兼容正則表達(dá)式 (PCRE)，網(wǎng)上可以找到很多驗(yàn)證正則表達(dá)式的站點(diǎn)，這里就不再展開(kāi)了。但要注意，為了方便配置，nginx 進(jìn)行了一些非標(biāo)準(zhǔn)的優(yōu)化，例如，不必像在標(biāo)準(zhǔn)正則表達(dá)式中那樣轉(zhuǎn)義 URL 中的正斜杠(/)等等。

而對(duì)于 ~ 和 ~* 唯一的區(qū)別就是：~ 區(qū)分大小寫(xiě)，而 ~* 不區(qū)分大小寫(xiě)。

總結(jié)

下面，我們對(duì) location 的選項(xiàng)進(jìn)行一個(gè)簡(jiǎn)單的總結(jié)

四、location 的應(yīng)用規(guī)則

理論篇

在了解完匹配規(guī)則后，我們來(lái)看下 nginx 是如何應(yīng)用這些規(guī)則的，這就要說(shuō)到 location 的順序問(wèn)題了。

下面是根據(jù)實(shí)踐以文檔總結(jié)出來(lái)的 location 應(yīng)用規(guī)則的邏輯：

• 將 server 塊中的 location 按照匹配模式分成兩個(gè)列表，分別為前綴字符串規(guī)則列表和正則匹配規(guī)則列表。
• 首先遍歷前綴字符串規(guī)則列表，當(dāng)滿(mǎn)足匹配的規(guī)則是精準(zhǔn)匹配時(shí)（即匹配選項(xiàng)是 =），直接應(yīng)用該規(guī)則，結(jié)束流程；否則找到匹配規(guī)則最長(zhǎng)的那條記錄（記作 maxLenthStringPrefixRule），繼續(xù)執(zhí)行邏輯3；
• 如果 maxLenthStringPrefixRule 存在且匹配選項(xiàng)是 ^~ ，應(yīng)用該規(guī)則，結(jié)束流程；否則，執(zhí)行邏輯4；
• 遍歷正則匹配規(guī)則列表，如果滿(mǎn)足匹配規(guī)則，則直接應(yīng)用，流程結(jié)束；如果直到循環(huán)結(jié)束后依然沒(méi)有滿(mǎn)足規(guī)則的 location，則執(zhí)行邏輯5；
• 如果 maxLenthStringPrefixRule 存在，則應(yīng)用該規(guī)則，流程結(jié)束；如果沒(méi)有則返回 404，同樣結(jié)束流程。

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

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

由此，我們可以得到幾個(gè)結(jié)論：

• 命中 = 匹配規(guī)則后會(huì)終止搜索，并直接使用該規(guī)則。所以，如果某個(gè)請(qǐng)求 url 頻繁發(fā)生，例如 /，我們可以在 nginx.conf 中添加 location = / 規(guī)則，這會(huì)加速這些請(qǐng)求的處理速度，因?yàn)樵诿幸?guī)則后會(huì)終止搜索。
• ^~ 和空串的前綴匹配，區(qū)別在于，如果命中 ^~ 的規(guī)則，并且是最長(zhǎng)前綴匹配，就會(huì)終止搜索正則匹配規(guī)則列表。
• 除了命中精準(zhǔn)匹配外，前綴字符串匹配列表都會(huì)被遍歷一遍，并且找到最長(zhǎng)匹配的那條 location 規(guī)則，所以前綴字符串匹配和在文件中的位置無(wú)關(guān)，但是和匹配長(zhǎng)度有關(guān)。
• 由于正則匹配的時(shí)間、資源消耗較多，所以 nginx 在對(duì) location 規(guī)則進(jìn)行正則匹配時(shí)，命中一個(gè)就直接使用了，所以正則匹配和 location 規(guī)則在文件中的位置有關(guān)

實(shí)踐篇

從上面的理論篇中，大家應(yīng)該能大致了解到 nginx 是如何命中 location 規(guī)則的，為了加深大家記憶，同時(shí)也為了能佐證理論是對(duì)的，我們來(lái)一些實(shí)踐吧。

我們的模板是這樣的，后面所有的實(shí)踐內(nèi)容，都是放到兩個(gè) rule section 之間。

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

精準(zhǔn)匹配優(yōu)先級(jí)最高

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';
}

我們?cè)?nginx.conf 放置了 /test、~ /test、= /test 三個(gè) location 規(guī)則，隨后在瀏覽器輸入 localhost:9001/test，發(fā)現(xiàn)輸出內(nèi)容是 = /test，符合我們的預(yù)期，= 選項(xiàng)的優(yōu)先級(jí)最高。

正則匹配和順序有關(guān)

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

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

隨后我們將 rule section 區(qū)塊替換成 ~ /test 和 ~ /test/*/demo 規(guī)則，在瀏覽器輸入 localhost:9001/test/xyz/demo，從正則角度來(lái)說(shuō)，/test/xyz/demo 既滿(mǎn)足 /test規(guī)則，又滿(mǎn)足 /test/*/demo 規(guī)則，但是由于 ~ /test 在文件中位置靠前，所以?xún)?yōu)先被命中，理論上應(yīng)該會(huì)輸出 ~ /test，校驗(yàn)后發(fā)現(xiàn)，確實(shí)是這樣。

正則、^~前綴匹配、空前綴匹配混搭

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 區(qū)域替換成上述內(nèi)容，然后在瀏覽器中輸入 localhost:9001/test/more/andmore，猜猜會(huì)發(fā)生什么？

我們來(lái)一起分析下：

• 沒(méi)有精準(zhǔn)匹配的規(guī)則
• 找到最長(zhǎng)的前綴字符串匹配規(guī)則是 /test/more/andmore，它不是 ^~ 選項(xiàng)，所以會(huì)遍歷正則匹配規(guī)則
• 發(fā)現(xiàn) ~ /test 滿(mǎn)足匹配規(guī)則，直接應(yīng)用該規(guī)則，所以會(huì)輸出 location ~ /test 規(guī)則塊的內(nèi)容，也就是 ~ /test

我們?cè)賮?lái)試一下，在瀏覽器輸入 localhost:9001/test/more，會(huì)顯示什么呢？

• 沒(méi)有精準(zhǔn)匹配規(guī)則
• 最長(zhǎng)前綴字符串匹配規(guī)則是 ^~ /test，是 ^~ 選項(xiàng)，所以不用遍歷正則匹配規(guī)則列表，所以頁(yè)面會(huì)顯示 ^~ /test。

通過(guò)校驗(yàn)后發(fā)現(xiàn)，上述分析的結(jié)果和實(shí)際顯示結(jié)果是一樣的。

上面幾個(gè)實(shí)踐都比較簡(jiǎn)單，大家也可以嘗試各種組合，然后按照上面的分析步驟來(lái)檢驗(yàn)下自己是不是真的理解了 location。

五、總結(jié)

看完上面的介紹，相信大家對(duì) location 規(guī)則的處理邏輯都有一定的了解，也應(yīng)該明白為什么在文章開(kāi)頭說(shuō)曾經(jīng)看到的結(jié)論對(duì)、也不對(duì)了。

如果要用對(duì) location 順序進(jìn)行總結(jié)的話(huà)，可以在原有的基礎(chǔ)上適當(dāng)?shù)倪M(jìn)行一些擴(kuò)展：

• 精準(zhǔn)匹配 =
• 前綴匹配 ^~，如果該前綴匹配是最長(zhǎng)前綴匹配規(guī)則，則應(yīng)用
• 正則匹配 ~、~*，和該規(guī)則在文件中的順序有關(guān)，執(zhí)行順序從上到下
• 不帶修飾符的前綴匹配，和匹配規(guī)則的長(zhǎng)度有關(guān)，只會(huì)應(yīng)用最長(zhǎng)的匹配規(guī)則，與在文件中的順序無(wú)關(guān)

參考鏈接：nginx.org/en/docs/htt…

到此這篇關(guān)于nginx location 順序問(wèn)題的文章就介紹到這了,更多相關(guān)nginx location 順序內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論