Nginx Location指令URI匹配规则详解

原文链接：http://blog.csdn.net/xyang81/article/details/51989079

1、介绍

location指令是http模块当中最核心的一项配置，根据预先定义的URL匹配规则来接收用户发送的请求，根据匹配结果，将请求转发到后台服务器、非法的请求直接拒绝并返回403、404、500错误处理等。

2、location指令语法

location [=|~|~*|^~|@] /uri/ { … } 或 location @name { … }

3、URI匹配模式

location指令分为两种匹配模式：
1> 普通字符串匹配：以=开头或开头无引导字符（～）的规则
2> 正则匹配：以～或～*开头表示正则匹配，~*表示正则不区分大小写

4、location URI匹配规则

当nginx收到一个请求后，会截取请求的URI部份，去搜索所有location指令中定义的URI匹配模式。在server模块中可以定义多个location指令来匹配不同的url请求，多个不同location配置的URI匹配模式，总体的匹配原则是：先匹配普通字符串模式，再匹配正则模式。只识别URI部份，例如请求为：/test/abc/user.do?name=xxxx
一个请求过来后，Nginx匹配这个请求的流程如下：
1> 先查找是否有=开头的精确匹配，如：location = /test/abc/user.do { … }
2> 再查找普通匹配，以 最大前缀 为原则，如有以下两个location，则会匹配后一项
* location /test/ { … }
* location /test/abc { … }
3> 匹配到一个普通格式后，搜索并未结束，而是暂存当前匹配的结果，并继续搜索正则匹配模式
4> 所有正则匹配模式location中找到第一个匹配项后，就以此项为最终匹配结果
所以正则匹配项匹配规则，受定义的前后顺序影响，但普通匹配模式不会
5> 如果未找到正则匹配项，则以3中缓存的结果为最终匹配结果
6> 如果一个匹配都没搜索到，则返回404

5、精确匹配与模糊匹配差别

location =/ { … } 与 location / { … } 的差别：
* 前一个是精确匹配，只响应/请求，所有/xxx或/xxx/xxxx类的请求都不会以前缀的形式匹配到它
* 后一个是只要以 / 为前缀的请求都会被匹配到。如：/abc ， /test/abc， /test/abc/aaaa

6、正则与非正则匹配

1> location ~ /test/.+.jsp$ { … } ：正则匹配，支持标准的正则表达式语法。
2> location ^~ / { … } ： ^~意思是关闭正则匹配，当搜索到这个普通匹配模式后，将不再继续搜索正则匹配模式。

...
http {
    ...
    server {
        listen       80;
        server_name  localhost;

        location / {
            root   html;
            index  index.html index.htm;
            # deny all; 拒绝请求，返回403
            # allow all; 允许请求
        }

        location /abc {
            deny all;
        }

        location ～ /.+\.jsp$ {
            proxy_pass http://location:9090;
        }

        # 匹配所有/test路径下的jsp文件
        location ~ /test/.+\.jsp$ {
            proxy_pass http://localhost:8080;
        }

        # 定义各类错误页
        error_page 404  /404.html

        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }

        # @类似于变量定义
        # error_page 403 http://blog.csdn.net; #这种定义不允许，需求利用@定义临时变量来实现
        error_page 403 @page403;
        location @page403 {
            proxy_pass http://blog.csdn.net;
        } 
    }
}