Nginx 匹配规则

Nginx 内核源码解析

nginx location 练习

Nginx location 配置踩坑过程分享
nginx配置location总结及rewrite规则写法
location 匹配规则

在页面输出 nginx 配置文件

server    {
    listen 80;
    server_name tmp.kaibuy.cn;
    index index.php;
    root  /home/web/blog/public/www;
    #error_page   404   /404.html;
    location / {
        default_type  text/plain;
        gzip off;
        set $str "This Host : ";
        return 200 "$str $http_host";
    }

    access_log off;
}

• default_type text/plain;是指定以文本方式打印，如果不加这句，搞不好会以下载文件的方式出现。当然也可以指定为HTML，具体代码见后面的mime.types中。
• gzip off;关闭压缩，也可以不关，这个不重要。
• set $str "This Host : ";设定一个变量，如果变量内容是单词，也可以：set $str MyValue;，这种不带引号时，中间不能有空格即可。
• return 200 "$str $http_host";返回内容体，前面200是状态码，可以是任意符合HTML状态码的代码，这任意。后面引号里的是两个变量，$str是刚才定义的变量，$http_host是nginx系统变量。这儿也可以写成return 200 $str$http_host;也就是不带引号，但变量之间要是连续的，不能有空格。

location  = / {
  # 精确匹配 / ，主机名后面不能带任何字符串
  [ configuration A ]
}
location  / {
  # 因为所有的地址都以 / 开头，所以这条规则将匹配到所有请求
  # 但是正则和最长字符串会优先匹配
  [ configuration B ]
}
location /documents/ {
  # 匹配任何以 /documents/ 开头的地址，匹配符合以后，还要继续往下搜索
  # 只有后面的正则表达式没有匹配到时，这一条才会采用这一条
  [ configuration C ]
}
location ~ /documents/Abc {
  # 匹配任何以 /documents/Abc 开头的地址，匹配符合以后，还要继续往下搜索
  # 只有后面的正则表达式没有匹配到时，这一条才会采用这一条
  [ configuration CC ]
}
location ^~ /images/ {
  # 匹配任何以 /images/ 开头的地址，匹配符合以后，停止往下搜索正则，采用这一条。
  [ configuration D ]
}
location ~* \.(gif|jpg|jpeg)$ {
  # 匹配所有以 gif,jpg或jpeg 结尾的请求
  # 然而，所有请求 /images/ 下的图片会被 config D 处理，因为 ^~ 到达不了这一条正则
  [ configuration E ]
}
location /images/ {
  # 字符匹配到 /images/，继续往下，会发现 ^~ 存在
  [ configuration F ]
}
location /images/abc {
  # 最长字符匹配到 /images/abc，继续往下，会发现 ^~ 存在
  # F与G的放置顺序是没有关系的
  [ configuration G ]
}
location ~ /images/abc/ {
  # 只有去掉 config D 才有效：先最长匹配 config G 开头的地址，继续往下搜索，匹配到这一条正则，采用
    [ configuration H ]
}
location ~* /js/.*/\.js

• 以=开头表示精确匹配
  如 A 中只匹配根目录结尾的请求，后面不能带任何字符串。
• ^~ 开头表示uri以某个常规字符串开头，不是正则匹配
• ~ 开头表示区分大小写的正则匹配;
• ~* 开头表示不区分大小写的正则匹配
• / 通用匹配, 如果没有其它匹配,任何请求都会匹配到

顺序 no优先级：
(location =) > (location 完整路径) > (location ^~ 路径) > (location _,* 正则顺序) > (location 部分起始路径) > (/)

• / -> config A
  精确完全匹配，即使/index.html也匹配不了
• /downloads/download.html -> config B
  匹配B以后，往下没有任何匹配，采用B
• /images/1.gif -> configuration D
  匹配到F，往下匹配到D，停止往下
• /images/abc/def -> config D
  最长匹配到G，往下匹配D，停止往下
  你可以看到 任何以/images/开头的都会匹配到D并停止，FG写在这里是没有任何意义的，H是永远轮不到的，这里只是为了说明匹配顺序
• /documents/document.html -> config C
  匹配到C，往下没有任何匹配，采用C
• /documents/1.jpg -> configuration E
  匹配到C，往下正则匹配到E
• /documents/Abc.jpg -> config CC
  最长匹配到C，往下正则顺序匹配到CC，不会往下到E

实际使用建议

所以实际使用中，个人觉得至少有三个匹配规则定义，如下：
直接匹配网站根，通过域名访问网站首页比较频繁，使用这个会加速处理，官网如是说。
这里是直接转发给后端应用服务器了，也可以是一个静态首页
第一个必选规则

location = / {
    proxy_pass http://tomcat:8080/index
}

第二个必选规则是处理静态文件请求，这是nginx作为http服务器的强项
有两种配置模式，目录匹配或后缀匹配,任选其一或搭配使用

location ^~ /static/ {
    root /webroot/static/;
}
location ~* \.(gif|jpg|jpeg|png|css|js|ico)$ {
    root /webroot/res/;
}

第三个规则就是通用规则，用来转发动态请求到后端应用服务器
非静态文件请求就默认是动态请求，自己根据实际把握
毕竟目前的一些框架的流行，带.php,.jsp后缀的情况很少了

location / {
    proxy_pass http://tomcat:8080/
}

常用正则

• . ： 匹配除换行符以外的任意字符
• ? ： 重复0次或1次
• • ： 重复1次或更多次
• • ： 重复0次或更多次
• \d ：匹配数字
• ^ ： 匹配字符串的开始
• $ ： 匹配字符串的介绍
• {n} ： 重复n次
• {n,} ： 重复n次或更多次
• [c] ： 匹配单个字符c
• [a-z] ： 匹配a-z小写字母的任意一个