关于location匹配规则那些事
- 1 概述
- 2 语法
- 3 匹配规则说明
- 3.1 精确匹配
- 3.2 前缀匹配（^~）
- 3.3 正则表达式匹配（\~和\~*）
- 3.4 普通前缀匹配
- 4 匹配优先级
- 5 注意事项
- 6 总结
大家好，我是欧阳方超，可以我的公众号“欧阳方超”，后续内容将在公众号首发。
1 概述
在nginx中，location块是一个重要的指令，用于定义如何处理特定的URI请求。本文将介绍location不同的匹配规则及它们的优先级。
2 语法
location语法格式
location [修饰符] URI {
...
}
修饰符包括：
=（精确匹配）
^~（优先前缀匹配）
~（区分大小写正则）
~*（不区分大小写正则）
空（不写修饰符，表示普通前缀匹配）
3 匹配规则说明
3.1 精确匹配
使用等号（=）表示精确匹配，只有当请求URI与指定路径完全一致时，此location才会被选中。
示例：
location = exact/path {
return 200 '精确匹配的内容';
}
请求必须完全匹配/path才会生效，例如：
[root@hadoop102 ~]# curl -k -L http://192.168.25.4/exact/path
精确匹配的内容
下面的路径均匹配不到：
[root@hadoop102 ~]# curl -k -L http://192.168.25.4/path1
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.24.0</center>
</body>
</html>
[root@hadoop102 ~]# curl -k -L http://192.168.25.4/path/
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.24.0</center>
</body>
</html>
注意，curl命令后添加 -L 选项以跟随重定向，否则curl结果只会显示第一个重定向的响应，而不会看到后续的https请求和响应（我的nginx做了配置，会把http请求重定向为https请求）。
或者curl后直接写https请求：
[root@hadoop102 ~]# curl -k https://192.168.25.4/exact/path
精确匹配的内容
精确匹配一般适用于需要严格匹配特定URI的场景，如某个特定的文件或资源。
3.2 前缀匹配（^~）
使用^~表示前缀匹配，如果请求URI以指定的前缀开始，且该location是所有非正则location中最长的匹配前缀，nginx将选择此规则并停止后续的正则表达式匹配。
location ^~ /prefix/ {
return 200 '前缀匹配';
}
[root@hadoop102 ~]# curl -k https://192.168.25.4/prefix/
前缀匹配
前缀匹配一般用户处理静态文件请求，提高性能，比如在
/usr/local/nginx/resources/目录想放一张图片giraffe.jpg，location写成如下形式：
location ^~ /prefix/ {
alias /usr/local/nginx/resources;
}
可以通过访问
https://192.168.25.4/prefix/giraffe.jpg请求到目录下的指定资源。
3.3 正则表达式匹配（~和~*）
~表示区分大小写的正则表达式匹配，~表示不区分大小写的正则表达式匹配。正则匹配适用于需要复杂匹配逻辑的场景，如文件扩展名或特定模式。例如下面的写法将会匹配所有以 .jpg, .jpeg 或 .png 结尾的请求，且区分大小写。
location ~ \.(gif|jpg|png)$ {
return 200 '匹配的图片类型的请求';
}
[root@hadoop102 ~]# curl -k https://192.168.25.4/test.gif
匹配的图片类型的请求
[root@hadoop102 ~]# curl -k https://192.168.25.4/test.Gif
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.24.0</center>
</body>
</html>
下面的写法将会匹配所有以.pdf或.doc结尾的请求，且不区分大小写。
location ~* \.(pdf|doc)$ {
return 200 '匹配到文档类型的请求';
}
[root@hadoop102 ~]# curl -k https://192.168.25.4/test.pdf
匹配到文档类型的请求
[root@hadoop102 ~]# curl -k https://192.168.25.4/test.pdF
匹配到文档类型的请求
使用注意事项
性能考虑：正则表达式比简单字符串或前缀匹配要慢，因此应尽量将常用且简单的路径放在前面，复杂的正则表达式放在后面，以提高性能。
避免过度复杂化：尽量使用简单明了的正则表达式，避免过于复杂的模式，这样有助于维护和理解配置。
测试与验证：使用工具或在线正则测试器来验证你的正则表达式是否按预期工作，以避免配置错误。
3.4 普通前缀匹配
普通前缀匹配是指没有指定任何修饰符的location指令，优先级最低，它用于捕获所有未被其他更具体的location规则匹配到的请求。通用匹配通常被称为“默认匹配”。在多个location规则中起到最后一道防线的作用。
通用匹配的配置形式为：
location / {
# 配置内容
}
这个规则会匹配所有请求URI，包括那些没有被其他特定规则捕获的请求，它类似于编程语言中switch-acse语句的default分支。
4 匹配优先级
nginx处理请求时，不同location对请求有不同的优先级，具体优先级顺序如下：
- 精确匹配（=）：最高优先级，完全匹配制定URI。
- 前缀匹配（^~）：一旦找到前缀匹配，停止后续查找。
- 正则表达式匹配（~和~*）：分为区分大小写和不区分大小写的正则匹配。
5 注意事项
- 正则表达式匹配时，不包含URI参数。例如对于请求"/test?arg=123"，匹配时只考虑"/test"部分
- location中的URI结尾是否带"/“会影响匹配结果:
location /test 可以匹配”/test"和"/test/"
location /test/ 只能匹配"/test/" - 如果多个location都可以匹配，按照优先级顺序只会执行一个
- 建议配置location时:
优先使用精确匹配
对于静态文件使用前缀匹配
需要正则时优先使用^~避免混淆
总是提供一个通用的location /作为默认匹配
6 总结
Nginx中的location块提供了多种方式来处理不同类型的请求。无论是静态文件服务、动态内容代理、URL重定向还是错误处理，合理地运用这些分类和优先级，可以帮助管理员高效地管理Web服务器，提高性能和用户体验。
我是欧阳方超，把事情做好了自然就有兴趣了，如果你喜欢我的文章，欢迎点赞、转发、评论加关注。我们下次见。