这作为一个备份,方便查询,毕竟nginx的强大,必然有其复杂性!

Location modifier
Nginx allows you to define location blocks by specifying a pattern that will be
matched against the requested document URI.
server {
server_name website.com;
location /admin/ {
# The configuration you place here only applies to
# http://website.com/admin/
}
}

location的匹配修饰符(modifier)有如下几种:

location [=|~|~*|^~|@] pattern { ... }

=   完全相等的匹配

~   区分大小写的带正则的匹配

~* 不区分大小写的带正则的匹配

^~ 类似无修饰符的匹配,URI一旦匹配到相关的请求(必须从URI头部开始)就停止再去匹配其他

@  命名修饰符,只能用于内部请求匹配

The = modifier
The requested document URI must match the specified pattern exactly. The pattern
here is limited to a simple literal string; you cannot use a regular expression:
server {
server_name website.com;
location = /abcd {
[…]
}
}
The configuration in the location block:
• Applies to http://website.com/abcd (exact match)
• Applies to http://website.com/ABCD (it is case-sensitive if your operating
system uses a case-sensitive filesystem)
• Applies to http://website.com/abcd?param1&param2 (regardless of query
string arguments)
• Does not apply to http://website.com/abcd/ (trailing slash)
• Does not apply to http://website.com/abcde (extra characters after the
specified pattern)
The ~ modifier
The requested URI must be a case-sensitive match to the specified regular expression:
server {
server_name website.com;
location ~ ^/abcd$ {
[…]
}
}
The ^/abcd$ regular expression used in this example specifies that the pattern
must begin (^) with /, be followed by abc, and finish ($) with d. Consequently,
the configuration in the location block:
• Applies to http://website.com/abcd (exact match)
• Does not apply to http://website.com/ABCD (case-sensitive)
• Applies to http://website.com/abcd?param1&param2 (regardless of query
string arguments)
• Does not apply to http://website.com/abcd/ (trailing slash) due to the
specified regular expression
• Does not apply to http://website.com/abcde (extra characters) due to the
specified regular expression
The ~* modifier
The requested URI must be a case-insensitive match to the specified regular expression:
server {
server_name website.com;
location ~* ^/abcd$ {
[…]
}
}
The regular expression used in the example is similar to the previous one.
Consequently, the configuration in the location block:
• Applies to http://website.com/abcd (exact match)
• Applies to http://website.com/ABCD (case-insensitive)
• Applies to http://website.com/abcd?param1&param2 (regardless of query
string arguments)
• Does not apply to http://website.com/abcd/ (trailing slash) due to the
specified regular expression
• Does not apply to http://website.com/abcde (extra characters) due to the
specified regular expression
The ^~ modifier
Similar to the no-symbol behavior, the location URI must begin with the specified
pattern. The difference is that if the pattern is matched, Nginx stops searching for
other patterns (read the section below about search order and priority).
The @ modifier
Defines a named location block. These blocks cannot be accessed by the client,
but only by internal requests generated by other directives, such as try_files or
error_page.
Search order and priority
Since it's possible to define multiple location blocks with different patterns, you
need to understand that when Nginx receives a request, it searches for the location
block that best matches the requested URI:
server {
server_name website.com;
location /files/ {
# applies to any request starting with "/files/"
# for example /files/doc.txt, /files/, /files/temp/
}
location = /files/ {
# applies to the exact request to "/files/"
# and as such does not apply to /files/doc.txt
# but only /files/
}
}
When a client visits http://website.com/files/doc.txt, the first location block
applies. However, when they visit http://website.com/files/, the second block
applies (even though the first one matches) because it has priority over the first one
(it is an exact match).
The order you established in the configuration file (placing the /files/ block before
the = /files/ block) is irrelevant. Nginx will search for matching patterns in a
specific order:
1. location blocks with the = modifier: If the specified string exactly matches
the requested URI, Nginx retains the location block.
2. location blocks with no modifier: If the specified string exactly matches the
requested URI, Nginx retains the location block.
3. location blocks with the ^~ modifier: If the specified string matches the
beginning of the requested URI, Nginx retains the location block.
4. location blocks with ~ or ~* modifier: If the regular expression matches the
requested URI, Nginx retains the location block.
5. location blocks with no modifier: If the specified string matches the
beginning of the requested URI, Nginx retains the location block.
In that extent, the ^~ modifier begins to make sense, and we can envision cases
where it becomes useful.

Case 1:
server {
server_name website.com;
location /doc {
[…] # requests beginning with "/doc"
}
location ~* ^/document$ {
[…] # requests exactly matching "/document"
}
}

You might wonder: when a client requests http://website.com/document, which
of these two location blocks applies? Indeed, both blocks match this request. Again,
the answer does not lie in the order in which the blocks appear in the configuration
files. In this case, the second location block will apply as the ~* modifier has
priority over the other.

Case 2:
server {
server_name website.com;
location /document {
[…] # requests beginning with "/document"
}
location ~* ^/document$ {
[…] # requests exactly matching "/document"
}
}
The question remains the same—what happens when a client sends a request
to download http://website.com/document? There is a trick here. The string
specified in the first block now exactly matches the requested URI. As a result, Nginx
prefers it over the regular expression.

Case 3:
server {
server_name website.com;
location ^~ /doc {
[…] # requests beginning with "/doc"
}
location ~* ^/document$ {
[…] # requests exactly matching "/document"
}
}
This last case makes use of the ^~ modifier. Which block applies when a client visits
http://website.com/document? The answer is the first block. The reason being
that ^~ has priority over ~*. As a result, any request with a URI beginning with /
doc will be affected to the first block, even if the request URI matches the regular
expression defined in the second block.

个人的观点,老外发明的东西或者提出的idea,最好看E文原版的资料,得到第一手的资料信息,中文翻译后,很多都比较难以考证或者不全。

nginx location各种修饰符的匹配优先级的更多相关文章

  1. 06 nginx Location详解之精准匹配

    一:Location详解之精准匹配 location 语法 location 有”定位”的意思, 根据Uri来进行不同的定位. 在虚拟主机的配置中,是必不可少的,location可以把网站的不同部分, ...

  2. 附001.Nginx location语法规则

    一 location规则 1.1 location语法 基本语法: location [=|~|~*|^~]/uri/{...} 修饰符释义: 1 = #表示精确严格匹配,只有请求的url路径与后面的 ...

  3. es6的正则扩展笔记之修饰符

    es6对于正则表达式添加了 u 修饰符和 y 修饰符. u 修饰符:含义为“Unicode模式”,用来正确处理大于\uFFFF的Unicode字符.    该修饰符不光会正确处理正则表达式,还会正确处 ...

  4. nginx location笔记

    nginx location笔记= 开头表示精确匹配^~ 开头表示uri以某个常规字符串开头,理解为匹配 url路径即可.nginx不对url做编码,因此请求为/static/20%/aa,可以被规则 ...

  5. nginx之location匹配优先级和安全问题

    最近一直在做location的配置,遇到优先级别问题(如有配置不当,会存在安全隐患),以下是个人的一些学习体会 一.location 匹配符 1.等于匹配符:      ##"=" ...

  6. Nginx——location匹配与在配置中的优先级

    1. location表达式类型 location ^~ /api/v7/ { proxy_next_upstream http_404 http_500 http_502 http_503 http ...

  7. Nginx location 匹配顺序整理

    Nginx location模块整理 具体的Nginx安装就不在这里描述了,这里只是为了对location的描述 Nginx环境 a. 查看当前系统cat /etc/redhat-release [r ...

  8. nginx——location 优先级

    一. location 的匹配符1.等于匹配符:=等于匹配符就是等号,特点可以概括为两点:精确匹配不支持正则表达式2.空匹配符空匹配符的特点是:匹配以指定模式开始的 URI不支持正则表达式3.正则匹配 ...

  9. Nginx location 匹配规则详解

    语法规则 location [=|~|~*|^~] /uri/ { … } 模式 含义 location = /uri = 表示精确匹配,只有完全匹配上才能生效 location ^~ /uri ^~ ...

随机推荐

  1. 在centos6.5中安装zookeeper集群

    简介 ZooKeeper服务器是用Java编写创建,它运行在JVM.所以需要使用JDK 6或更高版本,在这里就不说在centos安装jdk环境了,直接进入正题,我搭建的是 192.168.0.2, 1 ...

  2. (40) Aeroo 服务安装

    服务器 Odoo 8.0 操作系统: Ubuntu trusty14.04 说明:安装aeroo 要的要两个服务 areoo-docs 和 soffice 这里设定两个端口 8989 和 8100 = ...

  3. SourceForge无法访问的解决办法

    这一阵java框架spring和hibernate都有新版本了(spring2.5.5和hibernate3.2.6)想下载看看,却发现 SourceForge.net无法打开.刚才用Google搜索 ...

  4. Gradient Boost Decision Tree(GBDT)中损失函数为什么是对数形式

    由于最近要经常用到XGBOOST的包,不免对相关的GBDT的原理又重新学习了一遍, 发现其中在考虑损失函数的时候,是以对数log进行度量的,囿于误差平方和函数的印象 那么为什么是对数呢?可能是下面的原 ...

  5. UML用例图在实际项目中的应用

    对我而言,目前还不能很好地回答这个问题.从来没有在项目中使用过模型,这还是因为以前项目不靠建模也能完成,没有用户,哪来的需求分析呢?UML建模,决定你建的是鸡窝还是摩天大楼,但是我做过的项目甚至连鸡窝 ...

  6. js对汉字首字母排序

    var city = ["北京","天津","上海","重庆","杭州"];city.sort(fu ...

  7. [转]Android,Yocto,Meego构建系统的区别

    http://m.blog.csdn.net/blog/sonach_tjsd/6647829

  8. c# windows编程控件学习-1

    using System; using System.Collections.Generic; using System.ComponentModel; using System.Data; usin ...

  9. Android 开源组件 ----- Android LoopView无限自动轮转控件

    Android 开源组件 ----- Android LoopView无限自动轮转控件 2015-12-28 15:26 by 杰瑞教育, 32 阅读, 0 评论, 收藏, 编辑 一.组件介绍 App ...

  10. iOS学习之手势

    UIGestureRecognizer 为了完成手势识别,必须借助于手势识别器--UIGestureRecognizer,利用UIGestureRecognizer,能轻松识别用户在某个view上面做 ...