干货 | 一文彻底读懂nginx中的location指令

男娘i 2021-08-28 23:07 492阅读 0赞

## Nginx系列导读 ##

[给小白的 Nginx 10分钟入门指南][Nginx 10]

[Nginx编译安装及常用命令][Nginx]

[完全卸载nginx的详细步骤][nginx]

[Nginx 配置文件详解][Nginx 1]

[一文带你读懂Nginx反向代理][Nginx 2]

## 前言 ##

我们在讲解[ Nginx 配置文件详解][Nginx 1] 中， 把Nginx的主配置文件分成了三部分，如图：

![format_png][]

今天就带着大家继续学习Nginx主配置文件第三部分`http`块中的`location`指令

## 1、location 介绍 ##

`location`是Nginx中的块级指令(block directive)，location指令的功能是用来匹配不同的url请求，进而对请求做不同的处理和响应，这其中较难理解的是多个location的匹配顺序，本文会作为重点来解释和说明。

开始之前先明确一些约定，我们输入的网址叫做`请求URI`，nginx用请求URI与`location中配置的URI`做匹配。

## 2、localtion 语法 ##

location有两种匹配规则：

*  匹配URL类型，有四种参数可选，当然也可以不带参数。
    
    `location [ = | ~ | ~* | ^~ ] uri { … }`
 *  命名location，用@标识，类似于定于goto语句块。
    
    `location @name { … }`

### location匹配参数解释： ###

（1） `“=”` ，精确匹配

*  内容要同表达式完全一致才匹配成功

location = /abc/ {
      .....
     }
            
    # 只匹配http://abc.com/abc
    #http://abc.com/abc [匹配成功]
    #http://abc.com/abc/index [匹配失败]

（2） `“~”`，执行正则匹配，区分大小写。

location ~ /Abc/ {
      .....
    }
    #http://abc.com/Abc/ [匹配成功]
    #http://abc.com/abc/ [匹配失败]

（3）`“~*”`，执行正则匹配，忽略大小写

location ~* /Abc/ {
      .....
    }
    # 则会忽略 uri 部分的大小写
    #http://abc.com/Abc/ [匹配成功]
    #http://abc.com/abc/ [匹配成功]

（4）`“^~”`，表示普通字符串匹配上以后不再进行正则匹配。

location ^~ /index/ {
      .....
    }
    #以 /index/ 开头的请求，都会匹配上
    #http://abc.com/index/index.page  [匹配成功]
    #http://abc.com/error/error.page [匹配失败]

（5）不加任何规则

*  不加任何规则时，默认是大小写敏感，前缀匹配，相当于加了“~”与“^~”

location /index/ {
      ......
    }
    #http://abc.com/index  [匹配成功]
    #http://abc.com/index/index.page  [匹配成功]
    #http://abc.com/test/index  [匹配失败]
    #http://abc.com/Index  [匹配失败]
    # 匹配到所有uri

（6）`“@”`，nginx内部跳转

location /index/ {
      error_page 404 @index_error;
    }
    location @index_error {
      .....
    }
    #以 /index/ 开头的请求，如果链接的状态为 404。则会匹配到 @index_error 这条规则上。

## 3、location匹配顺序 ##

`=` > `^~` > `~ | ~*` > `最长前缀匹配` > `/`

序号越小优先级越高

1.  location =    \# 精准匹配
2.  location ^~   \# 带参前缀匹配
3.  location ~    \# 正则匹配（区分大小写）
4.  location ~\*   \# 正则匹配（不区分大小写）
5.  location /a   \# 普通前缀匹配，优先级低于带参数前缀匹配。
6.  location /    \# 任何没有匹配成功的，都会匹配这里处理

### 举例 ###

location = /  {
    #规则A
    }
    
    location = /login {
    #规则B
    }
    
    location ^~ /static/ {
    #规则C
    }
    
    location ~ \.(gif|jpg|png|js|css)$ {
    #规则D
    }
    
    location ~* \.png$ {
    #规则E
    }
    
    location !~ \.xhtml$ {
    #规则F
    }
    
    location !~* \.xhtml$ {
    #规则G
    }
    
    location / {
    #规则H
    }

匹配结果：

访问根目录/， 比如http://localhost/ 将匹配规则A
    
    访问 http://localhost/login 将匹配规则B，http://localhost/register 则匹配规则H
    
    访问 http://localhost/static/a.html 将匹配规则C
    
    访问 http://localhost/b.jpg 将匹配规则D和规则E，但是规则D顺序优先，规则E不起作用， 而 http://localhost/static/c.png 则优先匹配到 规则C
    
    访问 http://localhost/a.PNG 则匹配规则E， 而不会匹配规则D，因为规则E不区分大小写。
    
    访问 http://localhost/a.xhtml 不会匹配规则F和规则G，http://localhost/a.XHTML不会匹配规则G，因为不区分大小写。规则F，规则G属于排除法，符合匹配规则但是不会匹配到。
    
    访问 http://localhost/qll/id/1111 则最终匹配到规则H，因为以上规则都不匹配。

## 4、location URI结尾带不带 / ##

1.  如果 URI 结构是 https://domain.com/ 的形式，尾部有没有 / 都不会造成重定向。因为浏览器在发起请求的时候，默认加上了 / 。虽然很多浏览器在地址栏里也不会显示 / 。这一点，可以访问百度验证一下。
2.  如果 URI 的结构是 https://domain.com/some-dir/ 。尾部如果缺少 / 将导致重定向。因为**约定，URL 尾部的 / 表示目录，没有 / 表示文件**。所以访问 /some-dir/ 时，服务器会自动去该目录下找对应的默认文件。如果访问 /some-dir 的话，服务器会先去找 some-dir 文件，找不到的话会将 some-dir 当成目录，重定向到 /some-dir/ ，去该目录下找默认文件。

举个例子：

server {
        listen       9001;
        server_name  www.abc.com;
    
        location ~ /edu {
            proxy_pass http://127.0.0.1:8080;
         }
      }

我们访问`www.abc.com:9001/edu`，看下效果

![format_png 1][]

> 访问 /edu 时，服务器首先去找edu文件，找不到则将edu当做目录，重定向到 /edu/，在该目录下找默认文件。

但是如果想这两种请求对应不同的处理，就要明确增加不带/结尾的location配置。例如：

location  /doc {
      proxy_pass http://www.doc123.com
    }
    location  /doc/ {
      proxy_pass http://www.doc456.com
    }

# #

[Nginx 10]: https://mp.weixin.qq.com/s?__biz=MzI3NzQ4MTE4Mw%3D%3D&chksm=eb64d7d0dc135ec68f4f8d8944d6c05ab49f23afc4e64ceff5d836a791f69aa87fad8b3ab6bc&idx=2&lang=zh_CN&mid=2247484512&scene=21&sn=2f53da1239ecb08f06b94e145d1d415b&token=1752560613#wechat_redirect
[Nginx]: https://mp.weixin.qq.com/s?__biz=MzI3NzQ4MTE4Mw%3D%3D&chksm=eb64d732dc135e24b09a5f8170a844c3ffe72de52e30036f941c52966741ea62a645466698e9&idx=1&lang=zh_CN&mid=2247484546&scene=21&sn=1e0cc9f63efd08ab6d4fd20cadf948b4&token=1752560613#wechat_redirect
[nginx]: https://mp.weixin.qq.com/s?__biz=MzI3NzQ4MTE4Mw%3D%3D&chksm=eb64d732dc135e24995f54da43414abe3f585819fe7374a15149632de29af9c3932c8585dc65&idx=2&lang=zh_CN&mid=2247484546&scene=21&sn=4df733adf7c6f830565af40df679184c&token=1752560613#wechat_redirect
[Nginx 1]: https://mp.weixin.qq.com/s?__biz=MzI3NzQ4MTE4Mw%3D%3D&chksm=eb64d726dc135e3095beb47a262fdd42f194f6b1837911ab94c9d631df2dd4a74e9ab9ec0a0f&idx=1&lang=zh_CN&mid=2247484566&scene=21&sn=ca9aca3c9880f676e357b2485c9ecb96&token=1752560613#wechat_redirect
[Nginx 2]: https://blog.csdn.net/weixin_38889300/article/details/105781379
[format_png]: /images/20210726/f7712b9b438c4c59a95fd8a28705d47e.png
[format_png 1]: /images/20210726/a917a3eb248a484b9819e923da3b8f8b.png