nginx中的location匹配规则介绍

简要概述

location匹配的几个命令的说明,如下

符号 说明
~ 波浪线表示执行一个正则匹配,区分大小写
~* 表示执行一个正则匹配,不区分大小写
^~ ^~表示普通字符匹配,如果该选项匹配,只匹配该选项,不匹配别的选项,一般用来匹配目录
= 进行普通字符精确匹配
@ "@" 定义一个命名的 location,使用在内部定向时,例如 error_page, try_files

具体详情,请参加官方文档

官方文档理解

前缀匹配

前面带有/或者/documents/的为前缀匹配。前缀匹配中,长的前缀匹配会优先于较短的前缀。比如,同时适合//documents/的前缀匹配,则优先使用/documents/

具体事例,可以参加下面代码,规则2和规则3都是前缀匹配。

正则匹配

前面带有~*修饰符(不区分大小写)或~修饰符(区分大小写)的匹配为正则。nginx首先检查前缀匹配,记住匹配前缀的最长的匹配项。最后再按照在正则匹配出现的顺序搜索,在第一个适合的匹配项上终止,并使用相应的配置,不再对后面的正则匹配进行搜索了。

如果没有匹配到合适的正则匹配项的话,则就会使用前面记住的前缀匹配。

精确匹配

使用=修饰符定义的匹配项为精确匹配。如果找到完全匹配的内容,搜索将终止,直接使用精确匹配出的匹配项,不再搜索后续的匹配项。

例如,如果/请求频繁发生,则定义location = /将加快这些请求的处理速度,因为搜索将在第一次比较后立即终止

实例展示

官方给出了一个实例,这里展示,并做简要说明:

# 规则1[精确匹配]
location = / {
    # 将只会匹配到 "/",因为它是精确匹配。
}
# 规则2[前缀匹配]
location / {
    # 将会匹配类似于"/index.html"这样的请求。
    # 同时,它也会匹配到其他规则匹配不到任何请求
}
# 规则3[前缀匹配]
location /documents/ {
    # 将会匹配到类似于"/documents/document.html"这样的请求
    # 带有"/documents/"开头的路径,在规则1,规则4和规则5都匹配不到的情况下,都将会使用当前匹配。
}
# 规则4[正则匹配]
location ^~ /images/ {
    # 将会匹配到类似于"/images/1.gif"的请求。
    # 任何带啊有"/images/"开头的请求都会被转发到这里,虽然规则5也能匹配到"/images/1.gif",但是由于当前规则写在规则5之前,当前规则已经匹配,所以就不再向下匹配了。
}
# 规则5[正则匹配]
location ~* \.(gif|jpg|jpeg)$ {
    # 将会匹配到类似于结尾为".jpg"的请求。
    # 虽然规则3也能匹配到"/documents/1.jpg",但是由于本规则是正则匹配,所以会覆盖掉规则3的匹配。这就是正则匹配覆盖掉前缀匹配的例子。
}

另外,推荐大家去参考Nginx location 正则这里对规则做了非常详细的说明。

root 和alias指令区别

  • alias的实例

    location /img/ {
        alias /var/www/image/;
    }
    

    若按照上述配置的话,则访问/img/目录里面的文件时,ningx会自动去/var/www/image/目录找文件

  • root实例
    location /img/ {
        root /var/www/image;
    }
    

    若按照这种配置的话,则访问/img/目录下的文件时,nginx会去/var/www/image/img/目录下找文件。]

alias是一个目录别名的定义,root则是最上层目录的定义。

还有一个重要的区别是alias后面必须要用/结束,否则会找不到文件的,root则可有可无。

原文地址:https://www.cnblogs.com/hxsen/p/12688558.html

时间: 2024-08-25 15:38:57

nginx中的location匹配规则介绍的相关文章

Nginx之location 匹配规则详解

Nginx之location 匹配规则详解 关于一些对location认识的误区 1. location 的匹配顺序是"先匹配正则,再匹配普通". 矫正: location 的匹配顺序其实是"先匹配普通,再匹配正则".我这么说,大家一定会反驳我,因为按"先匹配普通,再匹配正则"解释不了大家平时习惯的按"先匹配正则,再匹配普通"的实践经验.这里我只能暂时解释下,造成这种误解的原因是:正则匹配会覆盖普通匹配(实际的规则,比这复杂,

nginx location 匹配规则

location匹配规则 ~             #波浪线表示执行一个正则匹配,区分大小写 ~*           #表示执行一个正则匹配,不区分大小写 !~和!~*    #分别为区分大小写不匹配及不区分大小写不匹配 ^~           #^~表示普通字符匹配,如果该选项匹配,只匹配该选项,不匹配别的选项,一般用来匹配目录 =             #进行普通字符精确匹配 @            #"@" 定义一个命名的 location,使用在内部定向时,例如 er

前端开发掌握nginx常用功能之server&location匹配规则

nginx主要是公司运维同学必须掌握的知识,涉及到反向代理.负载均衡等服务器配置.前端开发尤其是纯前端开发来说对nginx接触的并不多,但是在一些情况下,nginx还是需要前端自己来搞:例如我们公司的开发环境和测试环境,虽然qa可以帮助搞定配置,但是每新增一个前端模块或者模块nginx配置经常变更都求着qa搞,麻烦别人还不如自己来搞,这样更能理解自己的需求.这些都需要前端开发对nginx有所理解,下面我们来说说nginx最基础的server和location匹配规则. 1. server匹配规则

Nginx 配置指令location 匹配符优先级和安全问题【转】

Nginx配置指令location匹配符优先级和安全问题 使用nginx 很久了,它的性能高,稳定性表现也很好,得到了很多人的认可.特别是它的配置,有点像写程序一样,每行命令结尾一个";"号,语句块用"{}"括起来.配制好,直接nginx -t 检查配制情况,配制成功,直接运行:service nginx reload.服务器没有任何宕机情况下,实现平稳修改配置.最近一直在做location 配置,遇到优先级别问题(如果配置不当可能存在安全隐患哦),以下是个人学习一

JavaScript中正则表达式判断匹配规则以及常用的方法

JavaScript中正则表达式判断匹配规则以及常用的方法: 字符串是编程时涉及到的最多的一种数据结构,对字符串进行操作的需求几乎无处不在. 正则表达式是一种用来匹配字符串的强有力的武器.它的设计思想是用一种描述性的语言来给字符串定义一个规则,凡是符合规则的字符串,我们就认为它"匹配"了. \d可以匹配一个数字                 '00\d'可以匹配'007' ,'\d\d\d'可以匹配'010' \w可以匹配一个字母或数字      '\w\w'可以匹配'js' \s可

【转】nginx location匹配规则

转载请保留:http://www.nginx.cn/115.html location匹配命令 ~      #波浪线表示执行一个正则匹配,区分大小写~*    #表示执行一个正则匹配,不区分大小写^~    #^~表示普通字符匹配,如果该选项匹配,只匹配该选项,不匹配别的选项,一般用来匹配目录=      #进行普通字符精确匹配@     #"@" 定义一个命名的 location,使用在内部定向时,例如 error_page, try_files location 匹配的优先级(与

nginx之location匹配规则

1.概述 Nginx server块下的一个指令,每个server块可以包含多个location块. 2.作用 (1)基于Nginx服务器接收到的请求字符串(例如:server_name/usr-string),对除虚拟主机名称(也可以是ip别名)之外的字符串(例如:"/usr-string")进行匹配,对特定的匹配进行处理: (2)地址定向.数据缓存和应答控制等功能都是在这部分实现: (3)许多第三方模块的配置也是在location块中提供功能. 3.语法结构 Location [

Nginx之location匹配规则(个人总结)

Location匹配的url的语法规则: syntax: location [=|~|~*|^~|@] /uri/ { - } default: no context: server=            表示精确匹配 ^~             表示普通字符匹配,不继续匹配正则,一般用来匹配目录 ~            表示区分大小写的正则匹配 ~*              表示不区分大小写的正则匹配 !~ 和!~*       分别表示区分大小写和不区分大小写不匹配的正则 @    

Android中的Intent Filter匹配规则介绍

本文主要介绍了隐式Intent匹配目标组件的规则,若有叙述不清晰或是不准确的地方希望大家指出,谢谢大家: ) 1. Intent简介 Intent用于在一个组件(Component,如Activity.Service.Broadcast Receiver)中打开另一个组件. Intent可分为隐式(implicitly)和显式(explicitly)两种: Explicitly Intent:在知道要打开哪个具体的Component时使用,通过指定调用者和被调用者即可打开目标Component: