Nginx配置指令location匹配符优先级和安全问题

最近一直在做location 配置，遇到优先级别问题（如果配置不当可能存在安全隐患哦），以下是个人学习一点体会。

一、 location 的匹配符
1.等于匹配符：=
等于匹配符就是等号，特点可以概括为两点：
精确匹配
不支持正则表达式
2.空匹配符
空匹配符的特点是：
匹配以指定模式开始的 URI
不支持正则表达式
3.正则匹配符：~
正则匹配符是可以使用正则表达式的匹配符。不过这里要强调的是，一般来说~是指：
区分大小写的正则匹配
而~*表示：
不区分大小写的正则匹配
但是对于一些对大小写不敏感的操作系统，这两者没有区别。另外一个就是^~，其表示以指定模式开始的正则匹配。

4.内部访问符：@
一般用于错误页面等，这个暂不讨论。

二、匹配符优先级
1.=
2.空匹配符，满足精确匹配时
3.^~
4.~或~*
5.空匹配符，满足以指定模式开始时的匹配时
这样说比较抽象，我们来看例子吧。

2.1 等于匹配符与精确匹配时的空匹配符

看下面的例子（用到我们此前一起完成的Hello World模块）：
代码如下:
location /poechant {
    hello_world no1;
}

location = /poechant {
    hello_world no2;
}
如果我们的请求是http://my.domian/poechant，则我们发现两个location都与请求的 URI 匹配，这时根据我们的优先级顺序，第一个是精确匹配时的空匹配符，第二个是等于匹配符，所以第二个的优先级高，也就是应该输出：

hello_world, no2
同时也说明 Nginx 的 locatoin 不是按照配置文件中的书写顺序来匹配的。

2.2 精确匹配时的空匹配符与正则匹配的^~

下面这个例子中，两者开始都精确匹配了，连这个正则匹配都是精确匹配。
代码如下:
location ^~ ^/poechant$ {
    hello_world no1;
}

location /poechant {
    hello_world no2;
}
匹配哪一个？你测试一下，会得到：

hello_world, no2
与我们上面说的优先级顺序相吻合。
2.3 其他匹配优先级比较的实例
略

三、实战经验总结

1.location 匹配的优先级(来自实践总结中)
(location =) > (location 完整路径 >) >(location ^~ 路径) >(location ~* 正则) >(location 路径)
只要匹配到，其它的都会忽略，然后返回到改匹配。
用以下例子来测试：

代码如下:
#1   
location / {
   return 500;
}
#2
location /a/ {
    return 404;
}
#3
location ~* /.jpg$ {
    return 403;
}
#4
location ^~ /a/ {
    return 402;
}
#5
location  /a/1.jpg {
    return 401;
}
#6
location = /a/1.jpg {
    return 400;