Nginx Location 匹配规则最佳实践

2024-05-27码农

戳下方名片，关注并 星标！

回复「 1024 」获取 2TB 学习资源！

👉 体系化学习：

— 特色专栏 —

/ /

大家好，我是民工哥！

Nginx 是开源、高性能、高可靠的 Web 和反向代理服务器，支持热部署，几乎可以做到 7 * 24 小时不间断运行，还可在不间断服务的情况下对软件版本进行热更新。Nginx 性能非常牛逼，占用内存少、并发能力强、能支持高并发，支持绝大部分协议，如TCP、UDP、SMTP、HTTPS等。最重要的是， Nginx 是免费开源的且可以商业化，配置使用也比较简单。

在中国有众多互联网大厂，如百度、京东、新浪、网易、腾讯等都在使用 Nginx，也有很多高知名度的国外网站也在使用 Nginx，比如：Netflix、GitHub、SoundCloud、MaxCDN等。

官方网站：http://www.nginx.org

在学习 Nginx 技术栈的路上，有一个非常重要的知识点： nginx location匹配规则 ！

Nginx的location匹配顺序是Nginx配置中非常核心且重要的概念，它决定了Nginx如何处理进入服务器的请求。理解location匹配顺序不仅有助于优化Nginx的性能，还能确保网站或应用的正确运行。下面将详细阐述Nginx的location匹配顺序，并通过实例加以说明。

Nginx location匹配顺序详解

精确匹配 (=)

当请求的URI与location后的字符串完全相同时，Nginx会选择这个location块进行处理。这种匹配方式的优先级最高。例如：

location = /favicon.ico { # 处理favicon.ico的请求 }

只有当请求URI严格为/favicon.ico时，上述location块才会被使用。

最长字符串匹配 (无修饰符)

当请求的URI以某个location后的字符串开头，并且这个字符串是最长的，Nginx会选择这个location块。这种匹配方式根据前缀的字符数量来确定优先级，字符数越多优先级越高。例如：

location /images/ { # 处理以/images/开头的请求 }

location /images/jpg/ { # 处理以/images/jpg/开头的请求 }

对于请求/images/jpg/photo.jpg，第二个location块将被匹配，因为它有更长的匹配前缀。

正则表达式匹配 (~ 和 ~*)

正则表达式匹配允许定义更复杂的URI匹配模式。 ~ 表示区分大小写的正则匹配，而 ~* 表示不区分大小写的正则匹配。Nginx会按照配置文件中的顺序逐个检查正则表达式location块，直到找到第一个匹配的块。因此，正则表达式的顺序很重要。例如：

location ~ \.(gif|jpg|png)$ { # 处理以.gif、.jpg或.png结尾的请求（区分大小写） }

location ~* \.(GIF|JPG|PNG)$ { # 处理以.GIF、.JPG或.PNG结尾的请求（不区分大小写） }

在实际应用中，通常会将正则表达式location块放在配置文件的较后位置，以避免不必要的正则匹配开销。

前缀匹配 (^~)

如果请求的URI以某个字符串开头，并且这个字符串后面紧跟的不是/或任何字符，Nginx会选择匹配这个前缀的location块。这种匹配方式在找到精确匹配之前进行，但优先级低于精确匹配。例如：

location ^~ /static/ { # 处理以/static/开头的请求（但不包括子目录） }

对于请求/static/file.txt，上述location块将被匹配；但对于请求/static/subdir/file.txt，则不会匹配（除非没有其他更长的前缀匹配）。

然而，这个描述可能有些误导，因为实际上 ^~ 修饰符的行为更接近于「最长字符串匹配」的特殊情况，它在找到任何正则表达式位置块之前匹配最长的前缀。如果找到了与 ^~ 修饰的location匹配的前缀，Nginx将立即停止搜索并使用这个location，即使可能存在更长的匹配。因此，将 ^~ 放在这里描述可能是不准确的，它实际上应该在「最长字符串匹配」之前进行考虑。但请注意，不同版本的Nginx可能会有细微的行为差异，因此建议查阅具体版本的官方文档以获取最准确的信息。