Nginx：location配置模块的用法（一）

1. 概述

在Web服务器的配置中，Nginx的location指令扮演着至关重要的角色。它不仅是Nginx配置的核心组成部分，更是实现灵活路由和请求处理的关键。location指令允许服务器根据请求的URI执行不同的操作，从而为Web应用提供了强大的URL匹配和处理能力。

location指令的主要作用是根据用户请求的URI来决定如何处理这个请求。它可以将不同的请求映射到文件系统的不同路径，或者将请求转发到其他服务器。通过合理配置location，我们可以实现诸如静态文件服务、反向代理、负载均衡等多种功能。

在Nginx配置文件中，location指令通常位于server块内。一个server块可以包含多个location块，每个location块定义了一组特定的URI处理规则。当Nginx接收到一个HTTP请求时，它会根据请求的URI逐一匹配这些location块，直到找到最佳匹配。

location指令的灵活性体现在其多样的匹配方式上。它支持精确匹配、前缀匹配、正则表达式匹配等多种匹配模式。这些不同的匹配模式使得Nginx能够处理各种复杂的URL结构，满足不同Web应用的需求。

此外，location指令还可以与其他Nginx指令配合使用，如proxy_pass、rewrite、try_files等，进一步增强了其功能性。这种组合使用使得Nginx能够实现更复杂的请求处理逻辑，如URL重写、请求重定向、错误页面处理等。

然而，location指令的强大功能也带来了一定的复杂性。正确理解和使用location指令需要对其语法规则、优先级顺序、以及与其他指令的交互有深入的了解。不当的配置可能导致意外的行为，如请求被错误路由或无法访问某些资源。

因此，掌握location指令的用法对于Nginx管理员和Web开发者来说至关重要。通过深入学习location指令的各种用法和最佳实践，我们可以充分发挥Nginx的潜力，构建高效、安全、可扩展的Web应用。

在接下来的章节中，我们将详细探讨location指令的语法、匹配规则、优先级以及各种高级应用，帮助读者全面理解和掌握这一强大的Nginx配置工具。

2. location 指令基础

2.1 location 指令的语法

Nginx中的location指令是配置文件中最常用也最重要的指令之一。它定义了如何处理特定的URL请求，使得服务器能够根据不同的请求路径执行不同的操作。location指令的基本语法如下：

location [修饰符] 匹配模式 {
    ...
}

在这个语法结构中，"修饰符"是可选的，而"匹配模式"则是必须指定的。大括号内包含了当URL匹配成功时要执行的指令集。

修饰符用于定义location的匹配行为，常见的修饰符包括：

“=”：表示精确匹配。如果找到精确匹配，则立即停止搜索。

“^~”：表示如果该符号后面的字符是最佳匹配，则采用该规则，不再进行后续的正则表达式匹配。

“~”：表示区分大小写的正则匹配。

“~*”：表示不区分大小写的正则匹配。

如果没有修饰符，则表示前缀匹配。

匹配模式可以是一个字符串，也可以是一个正则表达式。Nginx会根据请求的URI与这个匹配模式进行比较，以决定是否应用该location块中的配置。

以下是一些location指令的实际例子：

location = / {
    ...
}

这个例子使用了"=“修饰符，表示精确匹配根路径”/"。

location ^~ /images/ {
    ...
}

这个例子使用了"^~“修饰符，表示如果请求的URI以”/images/"开头，就会使用这个location块的配置，且不再检查其他正则表达式location。

location ~ \.(gif|jpg|png)$ {
    ...
}

这个例子使用了"~“修饰符，表示对URI进行区分大小写的正则匹配。它会匹配所有以”.gif"、“.jpg"或”.png"结尾的请求。

location /documents/ {
    ...
}

这个例子没有使用修饰符，表示对"/documents/"路径进行前缀匹配。

在location块内部，我们可以使用各种Nginx指令来定义如何处理匹配的请求。常见的指令包括：

root：指定请求的根目录。

index：指定默认文件。

proxy_pass：将请求转发到另一个服务器。

try_files：按顺序检查文件是否存在。

return：返回特定的HTTP状态码。

例如：

location /images/ {
    root /data;
    try_files $uri $uri/ =404;
}

这个配置表示，对于以"/images/“开头的请求，Nginx会在”/data/images/"目录下查找对应的文件。如果文件不存在，则返回404错误。

理解location指令的语法是配置Nginx服务器的基础。通过灵活运用不同的修饰符和匹配模式，我们可以精确控制Nginx如何处理不同的URL请求，从而实现复杂的Web服务器功能。

2.2 location 指令的匹配规则

Nginx的location指令使用一套复杂而精密的匹配规则来决定如何处理incoming请求。理解这些匹配规则对于正确配置和优化Nginx服务器至关重要。

location指令的匹配过程可以概括为以下几个步骤：

首先，Nginx会检查所有的精确匹配规则（使用"="修饰符的location）。如果找到一个精确匹配，Nginx会立即停止搜索并使用该location块中的配置来处理请求。

如果没有找到精确匹配，Nginx会继续检查前缀匹配规则。在这个阶段，Nginx会记住最长的匹配，并继续搜索。如果遇到一个使用"^~"修饰符的location，且该location是最长匹配，Nginx会立即停止搜索并使用该location。

如果仍然没有找到匹配，或者找到的最长匹配没有"^~"修饰符，Nginx会继续进行正则表达式匹配。正则表达式匹配按照它们在配置文件中出现的顺序进行检查。一旦找到第一个匹配的正则表达式location，Nginx就会停止搜索并使用该location。

如果没有匹配的正则表达式location，Nginx会使用之前记住的最长前缀匹配的location。

这个匹配过程看似复杂，但在实际应用中非常强大和灵活。让我们通过一些具体的例子来深入理解这个过程：

假设我们有以下location配置：

location = / {
    # 精确匹配"/"
}

location / {
    # 匹配任何以"/"开头的请求
}

location /documents/ {
    # 匹配任何以"/documents/"开头的请求
}

location ^~ /images/ {
    # 匹配任何以"/images/"开头的请求
}

location ~* \.(gif|jpg|jpeg)$ {
    # 匹配任何以gif、jpg或jpeg结尾的请求
}

对于请求/，会精确匹配到第一个location。

对于请求/index.html，会匹配到第二个location。

对于请求/documents/document.html，会匹配到第三个location。

对于请求/images/1.gif，会匹配到第四个location。尽管它也满足最后一个正则表达式location，但由于"^~"修饰符的存在，Nginx会停止在第四个location。

对于请求/documents/1.jpg，会匹配到最后一个location。虽然它也满足第三个location，但正则表达式匹配的优先级更高。

理解这些匹配规则后，我们就可以更好地组织我们的location块。例如，我们可以将更具体的规则放在前面，将更通用的规则放在后面。我们也可以使用"^~"修饰符来确保某些特定的前缀匹配不会被后续的正则表达式匹配覆盖。

此外，在编写location匹配规则时，我们还需要注意以下几点：

路径匹配不包含查询字符串。例如，对于请求/index.html?param=value，location只会尝试匹配/index.html部分。

location中的正则表达式支持捕获组，可以在后续的配置中使用。例如：

location ~ ^/users/(.+)/files/(.+)$ {
    add_header X-User $1;
    add_header X-File $2;
}

对于请求/users/john/files/document.pdf，这个配置会添加两个响应头：X-User: john和X-File: document.pdf。

Nginx的location匹配是大小写敏感的。如果需要进行大小写不敏感的匹配，可以使用"~*"修饰符。

通过深入理解这些匹配规则，我们可以更好地控制Nginx如何处理不同的请求，从而构建更高效、更灵活的Web服务器配置。

2.3 location 指令的优先级

在Nginx配置中，location指令的优先级是一个关键概念，它决定了当多个location块可能匹配同一个请求时，Nginx将选择哪一个location块来处理该请求。理解这个优先级机制对于正确配置Nginx服务器至关重要。

Nginx的location指令优先级从高到低排序如下：

首先是精确匹配（=）。当Nginx遇到一个与请求URI完全相同的精确匹配location时，它会立即选择该location并停止搜索。这是最高优先级的匹配方式，通常用于处理特定的、明确的请求路径。例如：

location = /login {
    # 处理登录请求
}

这个location将精确匹配/login路径，而不会匹配/login/或/login.html。

其次是前缀匹配（~）。如果找到一个前缀匹配的location，且该location使用了~修饰符，Nginx会立即停止搜索并选择该location，即使后面可能有更精确的正则表达式匹配。这个修饰符常用于防止正则表达式location覆盖某些特定的前缀匹配。例如：

location ^~ /static/ {
    # 处理静态文件请求
}

这个location会匹配所有以/static/开头的请求，并且不会被后续的正则表达式location覆盖。

接下来是正则表达式匹配（~ 和 *）。**Nginx**会按照配置文件中正则表达式location出现的顺序进行匹配。一旦找到第一个匹配的正则表达式location，**Nginx**就会停止搜索并使用该location。区分大小写的正则表达式（）优先于不区分大小写的正则表达式（~*）。例如：

location ~ \.php$ {
    # 处理PHP文件请求
}

location ~* \.(jpg|jpeg|png|gif)$ {
    # 处理图片文件请求
}

最后是普通前缀匹配（无修饰符）。如果之前的匹配都未成功，Nginx会选择最长的匹配前缀location。这是最低优先级的匹配方式，通常用作默认处理或作为一个通用的回退选项。例如：

location / {
    # 处理所有其他请求
}

值得注意的是，在实际配置中，这些不同优先级的location可能会相互影响。例如，考虑以下配置：

location = /api {
    # 精确匹配/api
}

location ^~ /api/ {
    # 前缀匹配/api/
}

location ~ ^/api/.*\.json$ {
    # 正则匹配以.json结尾的/api/请求
}

location /api/ {
    # 普通前缀匹配/api/
}

在这个配置中，对于请求/api，会使用第一个location（精确匹配）。对于请求/api/users，会使用第二个location（^~前缀匹配），即使第三个location（正则匹配）可能也符合条件。对于请求/api/data.xml，会使用第二个location，而不是第四个location。

理解这种优先级机制可以帮助我们更好地组织Nginx配置，避免潜在的冲突和混淆。在实际应用中，我们通常会将更具体的规则放在前面，将更通用的规则放在后面。同时，我们也可以利用不同的修饰符来精确控制Nginx的匹配行为，从而实现复杂的路由和请求处理逻辑。

此外，在处理location优先级时，还需要注意一些细节。例如，正则表达式location的顺序很重要，因为Nginx会使用第一个匹配的正则表达式location。如果有多个可能匹配的正则表达式location，我们需要仔细考虑它们的顺序。

同时，使用^~修饰符可以有效地防止某些路径被正则表达式location意外匹配。这在处理静态文件或特定的API路径时特别有用。

3. location 匹配修饰符

Nginx的location指令支持多种匹配修饰符，这些修饰符决定了Nginx如何解释和匹配请求的URI。理解这些修饰符的作用和优先级对于正确配置Nginx服务器至关重要。本节将详细介绍四种主要的location匹配修饰符：精确匹配"=“、前缀匹配”^“、正则匹配”“和”~*"，以及普通匹配（无修饰符）。

3.1 精确匹配 =

精确匹配是Nginx location指令中优先级最高的匹配方式。当使用"="修饰符时，Nginx会将请求的URI与指定的模式进行精确比较。如果匹配成功，Nginx将立即停止搜索其他location块，并使用该location的配置来处理请求。

精确匹配通常用于处理特定的、明确的请求路径。例如：

location = / {
    # 仅匹配根路径"/"
}

location = /login {
    # 仅匹配"/login"路径
}

在这个配置中，第一个location块只会匹配根路径"/“，而不会匹配”/index.html"或任何其他路径。第二个location块只会匹配"/login"路径，而不会匹配"/login/“或”/login.html"。

使用精确匹配可以提高Nginx的处理效率，因为一旦找到匹配，Nginx就不需要继续搜索其他可能的匹配。这对于频繁访问的特定URI特别有用。

3.2 前缀匹配 ^~

前缀匹配使用"^~“修饰符，它的优先级仅次于精确匹配。当Nginx遇到使用”^~"修饰符的location时，如果该location是最长的前缀匹配，Nginx会立即停止搜索并选择该location，即使后面可能存在更精确的正则表达式匹配。

这个修饰符常用于防止正则表达式location覆盖某些特定的前缀匹配。例如：

location ^~ /static/ {
    # 处理所有以"/static/"开头的请求
}

在这个配置中，所有以"/static/"开头的请求都会被这个location处理，而不会被后续的正则表达式location匹配。这对于处理静态文件特别有用，可以避免不必要的正则表达式匹配，从而提高性能。

3.3 正则匹配 ~ 和 ~*

在 Nginx的location配置中，正则表达式匹配是一种强大而灵活的匹配方式。它允许我们使用复杂的模式来匹配 URL，从而实现更精细的请求处理。 Nginx提供了两种正则表达式匹配修饰符：~ 和 ~*。

修饰符用于区分大小写的正则表达式匹配。当使用这个修饰符时， Nginx会严格按照大小写来匹配 URL。例如：

location ~ \.php$ {
    fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
    fastcgi_index index.php;
    include fastcgi_params;
}

这个配置会匹配所有以".php"结尾的URL，但不会匹配".PHP"或".pHp"。这种严格匹配在处理特定文件类型时非常有用，可以确保只有正确的文件扩展名才会被处理。

~* 修饰符用于不区分大小写的正则表达式匹配。使用这个修饰符时，Nginx会忽略大小写差异。例如：

location ~* \.(gif|jpg|jpeg|png|ico)$ {
    expires 30d;
    add_header Cache-Control "public, no-transform";
}

这个配置会匹配所有以".gif"、“.jpg”、“.jpeg”、“.png"或”.ico"结尾的URL，不论这些扩展名是大写还是小写。这在处理图片文件时特别有用，因为文件扩展名的大小写可能会有所不同。

正则表达式匹配的优势在于其灵活性。我们可以使用各种正则表达式语法来精确控制匹配行为。例如：

location ~ ^/api/v[0-9]+/ {
    proxy_pass http://backend;
}

这个配置会匹配所有以"/api/v"开头，后面跟着一个或多个数字，再跟着"/"的URL。这可以用来处理不同版本的API请求。

在使用正则表达式匹配时，我们还可以利用捕获组来提取URL中的特定部分。例如：

location ~ ^/users/(\d+)/profile$ {
    set $user_id $1;
    proxy_pass http://user_service;
    proxy_set_header X-User-ID $user_id;
}

这个配置会匹配形如"/users/123/profile"的URL，并将用户ID（在这个例子中是"123"）捕获到变量$1中。然后，我们可以使用这个变量来设置自定义头部。

需要注意的是，正则表达式匹配在Nginx的location匹配顺序中具有较高的优先级。一旦找到匹配的正则表达式location，Nginx就会停止搜索并使用该location。因此，在配置多个正则表达式location时，我们需要仔细考虑它们的顺序。

此外，过度使用复杂的正则表达式可能会影响Nginx的性能。对于频繁访问的路径，使用前缀匹配或精确匹配可能会更高效。

正则表达式匹配还可以与其他Nginx指令结合使用，以实现更复杂的功能。例如，我们可以结合使用正则表达式location和rewrite指令来实现URL重写：

location ~ ^/old-api/(.*)$ {
    rewrite ^/old-api/(.*)$ /new-api/$1 last;
}

这个配置会将所有以"/old-api/“开头的请求重写为”/new-api/"开头的新URL。

正则表达式匹配（~ 和 ~*）为Nginx的location配置提供了强大的灵活性。通过合理使用这些修饰符，我们可以精确控制Nginx如何处理不同的URL请求，从而实现复杂的路由逻辑和请求处理。然而，在使用时也需要注意性能影响和配置复杂性，确保正则表达式匹配与其他location配置协调一致，以构建高效、可维护的Nginx服务器配置。

3.4 普通匹配（无修饰符）

普通匹配是最基本的location匹配方式，它不使用任何修饰符。普通匹配执行前缀匹配，但其优先级最低。如果请求URI与多个普通匹配location相匹配，Nginx会选择最长的匹配。

例如：

location / {
    # 匹配所有请求
}

location /api/ {
    # 匹配所有以"/api/"开头的请求
}

在这个配置中，对于请求"/api/users"，Nginx会选择第二个location，因为它是最长的匹配。对于请求"/index.html"，Nginx会选择第一个location。

普通匹配通常用作默认处理或作为一个通用的回退选项。它们常常放在配置文件的末尾，用于处理所有未被其他更具体的location匹配的请求。

理解这些不同的匹配修饰符及其优先级对于正确配置Nginx服务器至关重要。通过合理使用这些修饰符，我们可以创建灵活、高效的Nginx配置，精确控制如何处理不同的HTTP请求。在实际应用中，我们通常会结合使用多种匹配方式，以满足复杂的路由和请求处理需求。

3.5 提醒：location / 与 location = / 不同

千万需要注意，在 Nginx 配置中，location / 和 location = / 虽然看起来相似，但它们的行为有着重要的区别：

1. 匹配范围：
   

• location / 使用前缀匹配，会匹配所有以 / 开头的请求，包括 /index.html、/about、/images/logo.png 等。
• location = / 使用精确匹配，只会匹配根路径 /，不会匹配其他路径。

2. 优先级：
   

• location = / 的优先级高于 location /。
• 当请求为根路径 / 时，location = / 会被优先选择。

3. 性能影响：
   

• 对于根路径请求，location = / 通常会有更好的性能，因为 Nginx 可以立即停止搜索其他 location 块。

4. 常见用途：

• location / 常用于设置默认的处理规则或作为回退选项。
• location = / 常用于专门处理根路径请求，如设置网站首页。

示例配置：

location = / {
    # 只处理根路径请求
    try_files /index.html =404;
}

location / {
    # 处理所有其他请求
    try_files $uri $uri/ /index.html;
}

在这个配置中，根路径请求会由第一个 location 块处理，而所有其他请求会由第二个 location 块处理。理解这两种 location 指令的区别可以帮助你更精确地控制 Nginx 的路由行为，优化服务器性能。

Nginx：location配置模块的用法（二）：https://developer.aliyun.com/article/1582112