Nginx，一个改变世界的软件，其作者是一个俄罗斯人，俗称毛子，在国人的印象中，是一群晚饭后牵着大灰熊在小区楼下散步的彪汉。能写出这般顺滑的软件，可谓是心有猛虎细嗅蔷薇典型代表啊。
很多同学都被location规则绕得云里雾里，总是搞不清楚自己写的规则为什么没有生效。其实location复杂的匹配规则可以用一句话来概括——女生想用最省力的方法找合适的男生。好像更云里雾里了，且听我娓娓道来。

网上一些对location认识的误区我就不写在这里混淆视听了，直接写我认为是对的，而且确实是对的规则。

对于非正则匹配，nginx会检索完所有的非正则location条目，而正则匹配，nginx会在匹配到第一条正则后，停止检索。为什么被设计成这样？上文提到女生想用最省力的方法找合适的男生，计算机检索非正则匹配是非常轻松的，所以它会把非正则的所有条目都看完，而计算机检索正则匹配的时候，会进行大量的逻辑运算，这样很不省力，违背了nginx为高效而生的初衷，所以被设计为检索到第一条能匹配的正则就停止检索。这就说明了location 的执行逻辑跟 location 在配置文件里面的编辑顺序是有关系的。
上面的话换个说法：
Nginx服务器会首先会检查多个location中是否有普通的uri匹配，如果有多个匹配，会先记住匹配度最高的那个。然后再检查正则匹配，这里切记正则匹配是有顺序的，从上到下依次匹配，一旦匹配成功，则结束检查，并就会使用这个location块处理此请求。如果正则匹配全部失败，就会使用刚才记录普通uri匹配度最高的那个location块处理此请求。

女生视角总结来说：她们会把那些条件比写得比较明确清晰的男生全都看完，找到一个最合适的做备胎（非正则匹配），然后她们会去看一眼那些条件看起来比较好，但写得比较模糊的，比如说就写了个某某公司总经理（正则匹配）一找到有合适的，则选之，不会再继续看那些后面的，若看完这些总经理都没找到合适的，用备胎。此时如果你头顶上有北上广本地土著的光环"^~"，则会优先考虑。若你"="万达王公子，前面一切皆可抛啊。

总之；匹配优先规则如下：

➤优先级最高的是带有”=“修饰符的location区段，当请求的URI与指定的字符串精确匹配时，则nginx应用此段配置，不再看其他区段，女生视角来说，就是你刚好是王公子了。

➤第二优先级为带有"^~"的location区段，匹配到了“普通location ”后，不再需要继续匹配“正则location ”了，（^ 表示“非”，~ 表示“正则”，字符意思是：不要继续匹配正则）。女生视角来说，你是上海本地户口。

➤第三优先级为能匹配上的第一条正则匹配。女生视角来说，虽然你资料只写了个总经理，但颜值还不错，身高两米六。

➤第四优先级为不带修饰符的location区段，也就是普通字符串匹配。女生视角来说，前面那些正则都是画大饼的，还是去找备胎吧。

nginx location实验部分

为了更清晰的说明实验，我用到了一个第三方的nginx模块"echo-nginx-module"，模块安装请参考https://hqidi.com/82.html
主要配置文件如下：

#1
                    location  /abcd {
echo "现在匹配到的是 location  /abcd";
}

#2
                    location ~* /abcd {
echo "现在匹配到的是 location ~* /abcd";
}

#3
		    location ~ /abcd {
echo "现在匹配到的是 location ~ /abcd";
}

#4  
                    location ~ /abc {
echo "现在匹配到的是 location ~ /abc";
}

#5
                    location ^~ /abc {
echo "现在匹配到的是 location ^~ /abc";

#6
                    location = /abcd {
echo "现在匹配到的是 location = /abcd";
}

当配置文件如上所示时：

匹配到了带“=”号前缀的location区段，所以得出结论，当请求的URI与指定的字符串精确匹配时，“=”区段的匹配优先级最高。
现在把“=”区段注释掉，接着实验

[root@hqidi vhosts]# sed -i '27,$s/^/#/' location 
[root@hqidi vhosts]# cat !$
cat location
#1
                    location  /abcd {
echo "现在匹配到的是 location  /abcd";
}

#2
                    location ~* /abcd {
echo "现在匹配到的是 location ~* /abcd";
}

#3
		    location ~ /abcd {
echo "现在匹配到的是 location ~ /abcd";
}

#4  
                    location ~ /abc {
echo "现在匹配到的是 location ~ /abc";
}

#5
                    location ^~ /abc {
echo "现在匹配到的是 location ^~ /abc";
}

#6
#                    location = /abcd {
#echo "现在匹配到的是 location = /abcd";
#}
[root@hqidi vhosts]# r /usr
/usr/local/nginx/sbin/nginx -s reload

当配置文件如上所示时：

这里，有同学就会有疑问了，这不对啊，这不应该是匹配到带有本地土著光环的"^~"段吗？原来，他的优先级虽然高于正则匹配，但低于空前缀（location /abcd）的精确匹配，当我们请求https://hqidi.com/abcd 时，先会被"location /abcd"匹配上，前面说过，仅仅字符串匹配上，它还是不死心的，还会去按配置文件中出现的顺序进行正则匹配。为了验证这个说法，我们把第二和第三区段换个位置：

#1
                    location  /abcd {
echo "现在匹配到的是 location  /abcd";
}


#3
		    location ~ /abcd {
echo "现在匹配到的是 location ~ /abcd";
}

#2
                    location ~* /abcd {
echo "现在匹配到的是 location ~* /abcd";
}
#4  
                    location ~ /abc {
echo "现在匹配到的是 location ~ /abc";
}

#5
                    location ^~ /abc {
echo "现在匹配到的是 location ^~ /abc";
}

当配置文件如上所示时：

剔除干扰项，再次验证：

#1
#                    location  /abcd {
#echo "现在匹配到的是 location  /abcd";
#}


#3
		    location ~ /abcd {
echo "现在匹配到的是 location ~ /abcd";
}

#2
                    location ~* /abcd {
echo "现在匹配到的是 location ~* /abcd";
}
#4  
                    location ~ /abc {
echo "现在匹配到的是 location ~ /abc";
}

#5
                    location ^~ /abc {
echo "现在匹配到的是 location ^~ /abc";
}

当配置文件如上所示时：

可以看出土著光环生效了。
这个"^~"，一般用于控制静态文件：
location ^~ /static/ {
root /webroot/static/;
}
如果你要强行用于动态文件：

 location ~ .*\.(php|php5)?$
        {
                fastcgi_pass  127.0.0.1:9000;
                fastcgi_index index.php;
                include fastcgi.conf;
        }

        location ^~ /test/ {    #因为^~的优先级比~高，当访问test/1.php，将被此段匹配到
                # rules
        }

结果就是php文件不会被解析。

接着实验

#1
                    location  /abcd {
echo "现在匹配到的是 location  /abcd";
}


#3
		    location ~ /abcd {
echo "现在匹配到的是 location ~ /abcd";
}

#2
                    location ~* /abcd {
echo "现在匹配到的是 location ~* /abcd";
}
#4  
                    location ~ /abc {
echo "现在匹配到的是 location ~ /abc";
}

#5
#                    location ^~ /abc {
#echo "现在匹配到的是 location ^~ /abc";
#}

当配置文件如上所示时：

客户端请求https://hqidi.com/abcd的时候，"location /abcd"这个区段其实先被规则匹配到，不过规则查找并没有停止，继续去查找有没有能匹配上的正则，如果有，就使用该正则匹配，并停止正则检索。
匹配优先级验证完毕，最后看一个最长匹配是什么鬼，最长匹配在女生视角很好理解，她们总是喜欢长的。。。最长匹配其实很简单，就是看起来最像的优先匹配。

          location ^~ /images/ {
echo "现在匹配到的是^~ /images/";
        }
          location /images/1/ {
echo "现在匹配到的是/images/1/";
        }

当配置文件如上所示时：

最后，希望看完的你没晕。。

原创文章转载请注明：Nginx的location规则迷之匹配 | 笛声博客

若你觉得本文对你有帮助，请博主喝一杯卡布奇板蓝根吧