亲宝软件园·资讯

展开

nginx location 顺序

月亮与六便士丶 人气:3

网上有很多讨论 nginx location 顺序的话题,得到的结论也基本一致,总结为:

在很长的一段时间里,我对上述的结论也一直深信不疑,甚至还将这个结论分享给其他小伙伴,直到在有一次配置时发现,请求 uri 明明是符合了前缀匹配 ^~ 规则,但 nginx 却没有使用,这让我对上述结论产生了疑惑。后续通过调研、实践后发现,上述结论可以说对,但也不对,是不是更疑惑了?没关系,看完这篇文章你就知道我为什么会这样说了。

本篇文章会从以下五个方面来介绍 location 顺序问题

话不多说,我们直接进入正题。

一、location 是什么

location 翻译成中文就是定位,已经描述的比较清晰了,因为它的作用就是根据请求 uri 定位到某一个规则块,然后在由该规则块决定怎么处理用户的请求。

location 模块看起来挺简单的,但真要自己写,有时候就会觉得无从下手,我应该用 location /imageslocation ^~ /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 应用规则的逻辑:

如果上述描述看着很难理解,可以尝试看下面的伪代码。

// 字符串匹配的规则集合,按照在 .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)

由此,我们可以得到几个结论:

实践篇

从上面的理论篇中,大家应该能大致了解到 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,猜猜会发生什么?

我们来一起分析下:

我们再来试一下,在浏览器输入 localhost:9001/test/more,会显示什么呢?

通过校验后发现,上述分析的结果和实际显示结果是一样的。

上面几个实践都比较简单,大家也可以尝试各种组合,然后按照上面的分析步骤来检验下自己是不是真的理解了 location

五、总结

看完上面的介绍,相信大家对 location 规则的处理逻辑都有一定的了解,也应该明白为什么在文章开头说曾经看到的结论对、也不对了。

如果要用对 location 顺序进行总结的话,可以在原有的基础上适当的进行一些扩展:

参考链接:nginx.org/en/docs/htt…

加载全部内容

相关教程
猜你喜欢
用户评论