由于团队在进行前后端分离,前端接管了 Nginx 和 node 层,在日常的工作中,跟 Nginx 打交道的时候挺多的。其中 location 是使用最多和改动最多的地方。之前对 location 的匹配规则是一知半解的。为了搞明白 location 是如何匹配的,特意花了点时间查了些资料,总结此文。希望能给大家带来帮助。
语法规则
location [ = | ~ | ~* | ^~ ] uri { ... } location @name { ... }
语法规则很简单,一个location关键字,后面跟着可选的修饰符,后面是要匹配的字符,花括号中是要执行的操作。
修饰符
匹配过程
对请求的 url 序列化。例如,对%xx等字符进行解码,去除 url 中多个相连的/,解析 url 中的.,..等。这一步是匹配的前置工作。
location 有两种表示形式,一种是使用前缀字符,一种是使用正则。如果是正则的话,前面有~或~*修饰符。
具体的匹配过程如下:
首先先检查使用前缀字符定义的 location,选择最长匹配的项并记录下来。
如果找到了精确匹配的 location,也就是使用了=修饰符的 location,结束查找,使用它的配置。
然后按顺序查找使用正则定义的 location,如果匹配则停止查找,使用它定义的配置。
如果没有匹配的正则 location,则使用前面记录的最长匹配前缀字符 location。
基于以上的匹配过程,我们可以得到以下两点启示:
示例
接下来我们以一个例子来具体说明一下匹配过程。
假如我们有下面的一段配置文件:
location = / { [ configuration A ] } location / { [ configuration B ] } location /user/ { [ configuration C ] } location ^~ /images/ { [ configuration D ] } location ~* \.(gif|jpg|jpeg)$ { [ configuration E ] }
请求/精准匹配 A,不再往下查找。
请求/index.html匹配 B。首先查找匹配的前缀字符,找到最长匹配是配置 B,接着又按照顺序查找匹配的正则。结果没有找到,因此使用先前标记的最长匹配,即配置 B。
请求/user/index.html匹配 C。首先找到最长匹配 C,由于后面没有匹配的正则,所以使用最长匹配 C。
请求/user/1.jpg匹配 E。首先进行前缀字符的查找,找到最长匹配项 C,继续进行正则查找,找到匹配项 E。因此使用 E。
请求/images/1.jpg匹配 D。首先进行前缀字符的查找,找到最长匹配 D。但是,特殊的是它使用了^~修饰符,不再进行接下来的正则的匹配查找,因此使用 D。这里,如果没有前面的修饰符,其实最终的匹配是 E。大家可以想一想为什么。
请求/documents/about.html匹配 B。因为 B 表示任何以/开头的 URL 都匹配。在上面的配置中,只有 B 能满足,所以匹配 B。
location @name 的用法
@用来定义一个命名 location。主要用于内部重定向,不能用来处理正常的请求。其用法如下:
location / { try_files $uri $uri/ @custom } location @custom { # ...do something }
上例中,当尝试访问 url 找不到对应的文件就重定向到我们自定义的命名 location(此处为 custom)。
值得注意的是,命名 location 中不能再嵌套其它的命名 location。
URL 尾部的/需不需要
关于 URL 尾部的/有三点也需要说明一下。第一点与 location 配置有关,其他两点无关。
location 中的字符有没有/都没有影响。也就是说/user/和/user是一样的。
如果 URL 结构是https://domain.com/的形式,尾部有没有/都不会造成重定向。因为浏览器在发起请求的时候,默认加上了/。虽然很多浏览器在地址栏里也不会显示/。这一点,可以访问baidu验证一下。
如果 URL 的结构是https://domain.com/some-dir/。尾部如果缺少/将导致重定向。因为根据约定,URL 尾部的/表示目录,没有/表示文件。所以访问/some-dir/时,服务器会自动去该目录下找对应的默认文件。如果访问/some-dir的话,服务器会先去找some-dir文件,找不到的话会将some-dir当成目录,重定向到/some-dir/,去该目录下找默认文件。可以去测试一下你的网站是不是这样的。
总结
location 的配置有两种形式,前缀字符和正则。查找匹配的时候,先查找前缀字符,选择最长匹配项,再查找正则。正则的优先级高于前缀字符。
正则等查找是按照在配置文件中的顺序进行的。因此正则等顺序很重要,建议越精细的放的越靠前。
使用=精准匹配可以加快查找的顺序,如果根域名经常被访问等话建议使用=。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持小牛知识库。
本文向大家介绍简介Nginx中的location匹配规则,包括了简介Nginx中的location匹配规则的使用技巧和注意事项,需要的朋友参考一下 location匹配命令 ~ #波浪线表示执行一个正则匹配,区分大小写 ~* #表示执行一个正则匹配,不区分大小写 ^~ #^~表示普通字符匹配,如果该选项匹配,只匹配该选项,不匹配别的选项,一般用来匹配目录 = #进行
本文向大家介绍详解Nginx location 匹配规则,包括了详解Nginx location 匹配规则的使用技巧和注意事项,需要的朋友参考一下 语法规则 location [=|~|~*|^~] /uri/ { … } 模式 含义 location = /uri = 表示精确匹配,只有完全匹配上才能生效 location ^~ /uri ^~ 开头对URL路径进行前缀匹配,并且在正则之前。 l
本文向大家介绍一篇文章弄懂Spring MVC的参数绑定,包括了一篇文章弄懂Spring MVC的参数绑定的使用技巧和注意事项,需要的朋友参考一下 前言 参数绑定,简单来说就是客户端发送请求,而请求中包含一些数据,那么这些数据怎么到达 Controller ?这在实际项目开发中也是用到的最多的,那么 SpringMVC 的参数绑定是怎么实现的呢? 下面我们来详细的讲解。 SpringMVC参数绑定
语法规则 location [=|~|~*|^~] /uri/ { … } 模式 含义 location = /uri = 表示精确匹配,只有完全匹配上才能生效 location ^~ /uri ^~ 开头对URL路径进行前缀匹配,并且在正则之前。 location ~ pattern 开头表示区分大小写的正则匹配 location ~* pattern 开头表示不区分大小写的正则匹配 locat
本文向大家介绍nginx location中uri的截取的实现方法,包括了nginx location中uri的截取的实现方法的使用技巧和注意事项,需要的朋友参考一下 说明: location 中的 root 和 alias root 指令只是将搜索的根设置为 root 设定的目录,即不会截断 uri,而是使用原始 uri 跳转该目录下查找文件 aias 指令则会截断匹配的 uri,然后使用 al
本文向大家介绍nginx配置location方法总结,包括了nginx配置location方法总结的使用技巧和注意事项,需要的朋友参考一下 location匹配顺序 1."="前缀指令匹配,如果匹配成功,则停止其他匹配 2.普通字符串指令匹配,顺序是从长到短,匹配成功的location如果使用^~,则停止其他匹配(正则匹配) 3.正则表达式指令匹配,按照配置文件里的顺序,成功就停止其他匹配 4.如
如果配置是 访问 http://localhost:8002/about/ 会返回 403 禁止 访问 http://localhost:8002/about/ 会返回 html 目录下的 index.html 文件,这是符合预期的 访问 http://localhost:8002/about/ 会不断进行重定向生成 http://localhost:8002/about/index.html/i
只有这一个地方配置了 8001 端口。 打算是通过访问 http://localhost:8001/about/ 打开 html 目录下的 about.html 的,但是返回 403 错误。如果是访问 http://localhost:8001/ 会返回 html 目录下的 index.html 文件 如果注释了这里的配置,那么 http://localhost:8001/ 是无法访问的。也就是配