性能文章>彻底弄懂 Nginx location 匹配>

彻底弄懂 Nginx location 匹配原创

544317

Nginx 的 location 实现了对请求的细分处理,有些 URI 返回静态内容,有些分发到后端服务器等,今天来彻底弄懂它的匹配规则

一个最简单的 location 的例子如下

server {
    server_name website.com;
    location /admin/ {
    # The configuration you place here only applies to
    # http://website.com/admin/
    }
}

location 支持的语法 location [=|~|~*|^~|@] pattern { … },乍一看还挺复杂的,来逐个看一下。

location修饰符类型

「=」 修饰符:要求路径完全匹配

server {
    server_name website.com;
    location = /abcd {
    […]
    }
}

「~」修饰符:区分大小写的正则匹配

server {
    server_name website.com;
    location ~ ^/abcd$ {
    […]
    }
}

^/abcd$这个正则表达式表示字符串必须以/开始,以$结束,中间必须是abcd

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

server {
    server_name website.com;
    location ~* ^/abcd$ {
    […]
    }
}

##「^~」修饰符:前缀匹配
如果该 location 是最佳的匹配,那么对于匹配这个 location 的字符串, 该修饰符不再进行正则表达式检测。注意,这不是一个正则表达式匹配,它的目的是优先于正则表达式的匹配

查找的顺序及优先级

当有多条 location 规则时,nginx 有一套比较复杂的规则,优先级如下:

  • 精确匹配 =
  • 前缀匹配 ^~(立刻停止后续的正则搜索)
  • 按文件中顺序的正则匹配 ~或~*
  • 匹配不带任何修饰的前缀匹配。

这个规则大体的思路是

先精确匹配,没有则查找带有 ^~的前缀匹配,没有则进行正则匹配,最后才返回前缀匹配的结果(如果有的话)

如果上述规则不好理解,可以看下面的伪代码(非常重要)

function match(uri):
  rv = NULL
  
  if uri in exact_match:
    return exact_match[uri]
  
  if uri in prefix_match:
    if prefix_match[uri] is '^~':
      return prefix_match[uri]
    else:
      rv = prefix_match[uri] // 注意这里没有 return,且这里是最长匹配
   
  if uri in regex_match:
    return regex_match[uri] // 按文件中顺序,找到即返回
  return rv

一个简化过的Node.js写的代码如下

function ngx_http_core_find_location(uri, static_locations, regex_locations, named_locations, track) {
  let rc = null;
  let l = ngx_http_find_static_location(uri, static_locations, track);
  if (l) {
    if (l.exact_match) {
      return l;
    }
    if (l.noregex) {
      return l;
    }
    rc = l;
  }
  if (regex_locations) {
    for (let i = 0 ; i < regex_locations.length; i ++) {
      if (track) track(regex_locations[i].id);
      let n = null;
      if (regex_locations[i].rcaseless) {
        n = uri.match(new RegExp(regex_locations[i].name));
      } else {
        n = uri.match(new RegExp(regex_locations[i].name), "i");
      }
      if (n) {
        return regex_locations[i];
      }
    }
  }

  return rc;
}

案例分析

案例 1

server {
    server_name website.com;
    location /doc {
        return 701; # 用这样的方式,可以方便的知道请求到了哪里
    }
    location ~* ^/document$ {
        return 702; # 用这样的方式,可以方便的知道请求到了哪里

    }
}

curl -I  website.com:8080/document
HTTP/1.1 702

按照上述的规则,第二个会有更高的优先级

案例2

server {
    server_name website.com;
    location /document {
        return 701;
    }
    location ~* ^/document$ {
        return 702;
    }
}
curl -I  website.com:8080/document

第二个匹配了正则表达式,优先级高于第一个普通前缀匹配

案例 3

server {
    server_name website.com;
    location ^~ /doc {
        return 701;
    }
    location ~* ^/document$ {
        return 702;
    }
}
curl http://website.com/document
HTTP/1.1 701

第一个前缀匹配^~命中以后不会再搜寻正则匹配,所以会第一个命中

案例 4

server {
    server_name website.com;
    location /docu {
        return 701;
    }
    location /doc {
        return 702;
    }
}

curl -I website.com:8080/document 返回 HTTP/1.1 701,

server {
    server_name website.com;
    location /doc {
        return 702;
    }
    location /docu {
        return 701;
    }
}

curl -I website.com:8080/document 依然返回 HTTP/1.1 701

前缀匹配下,返回最长匹配的 location,与 location 所在位置顺序无关

案例 5

server {
	listen 8080;
	server_name website.com;

    location ~ ^/doc[a-z]+ {
        return 701;
    }

    location ~ ^/docu[a-z]+ {
        return 702;
    }
}

curl -I website.com:8080/document 返回 HTTP/1.1 701

把顺序换一下

server {
	listen 8080;
	server_name website.com;

    location ~ ^/docu[a-z]+ {
        return 702;
    }
    
    location ~ ^/doc[a-z]+ {
        return 701;
    }
}

curl -I website.com:8080/document 返回 HTTP/1.1 702

正则匹配是使用文件中的顺序,找到返回

分类:
标签:
请先登录,再评论

好文

1年前

为你推荐

一次百万长连接压测 Nginx OOM 的问题排查分析
在最近的一次百万长连接压测中,32C 128G 的四台 Nginx 频繁出现 OOM,出现问题时的内存监控如下所示。排查的过程记录如下。 现象描述这是一个 websocket 百万长连接收发消息的压测
Nginx 502 Bad Gateway
前言事实证明,读过Linux内核源码确实有很大的好处,尤其在处理问题的时刻。当你看到报错的那一瞬间,就能把现象/原因/以及解决方案一股脑的在脑中闪现。甚至一些边边角角的现象都能很快的反应过来是为何。笔
RocketMQ 在使用上的一些排坑和优化
前言:RocketMQ 在我们的项目中使用非常广泛,在使用的过程中,也遇到了很多的问题。比如没有多环境的隔离,在多个版本同时开发送测的情况下,互相干扰严重。RocketMQ 的投递可能会失败,导致丢失
MySQL 死锁套路:一次诡异的批量插入死锁问题分析
线上最近出现了批量insert的死锁,百思不得解。死锁记录如下:```2018-10-26T11:04:41.759589Z 8530809 [Note] InnoDB: (1) TRANSACTI
通过调试 Nginx 源码来定位有趣 Nginx 转发合并斜杠和编码问题
背景前段时间出现了一个请求在测试环境签名成功,在线上环境签名失败的情况,排查原因是线上url中有双斜杠会被合并成一个传给后端,在测试环境中不会出现。这个就比较神奇了,Nginx 版本完全一样。确认问题
由 JVM Attach API 看跨进程通信中的信号和 Unix 域套接字
在 JDK5 中,开发者只能 JVM 启动时指定一个 javaagent 在 premain 中操作字节码,Instrumentation 也仅限于 main 函数执行前,这样的方式存在一定的局限性。
彻底弄懂 Nginx location 匹配
Nginx 的 location 实现了对请求的细分处理,有些 URI 返回静态内容,有些分发到后端服务器等,今天来彻底弄懂它的匹配规则一个最简单的 location 的例子如下```server {
一种探究 InnoDB 的存储格式的新方式
文件的存储结构包含了系统大量的实现细节,比如 java 的 class 文件结构,rocksdb 的存储结构。MySQL InnoDB 的存储格式比较复杂,但确实我们理解 MySQL 技术内幕不必可少