Nginx location 匹配规则：看这篇就够了

Nginx 是一款高性能的开源 Web 服务器、反向代理服务器以及邮件代理服务器。它以其高并发能力和低内存消耗而闻名。在 Nginx 的配置中，location 块是路由请求的核心。理解 location 块的匹配规则对于正确配置 Nginx 至关重要，它决定了特定的请求 URI (统一资源标识符) 将由哪个块来处理，从而决定了如何响应客户端请求（例如，是返回静态文件、转发给应用服务器、执行特定的重写规则等）。

许多 Nginx 用户在配置 location 块时会感到困惑，特别是当多个 location 块都可能匹配同一个请求 URI 时，Nginx 会如何选择？本文将深入剖析 Nginx location 的匹配机制，详细介绍各种匹配类型、修饰符以及它们之间的优先级和匹配顺序，旨在帮助你彻底理解 Nginx 的路由逻辑。

1. `location` 指令的基本语法

location 指令通常放在 server 块中，用于根据请求的 URI 来定义不同的配置。其基本语法如下：

nginx location [ modifier ] pattern { # 配置指令，例如： # root /path/to/root; # index index.html; # proxy_pass http://backend; # rewrite ...; # return ...; }

modifier：是可选的，用于改变 pattern 的匹配方式。不同的修饰符决定了 pattern 是如何被解释和匹配的。
pattern：是用于与请求 URI 进行匹配的模式。它可以是前缀字符串、精确字符串或正则表达式。
花括号 {} 内是当请求 URI 匹配到这个 location 块时，Nginx 将执行的一系列指令。

现在，让我们详细看看不同的 modifier 和 pattern 如何组合，以及它们各自的含义。

2. `location` 的主要匹配类型

Nginx 的 location 匹配主要分为两大类：前缀匹配 和 正则表达式匹配。通过不同的修饰符来区分它们。

2.1 前缀匹配 (Prefix Matching)

前缀匹配是 location 匹配中最简单和最常用的类型。它不使用任何修饰符，或者使用 ^~ 修饰符（我们稍后会详细介绍 ^~ 的特殊作用）。

语法:
nginx location pattern { ... } location ^~ pattern { ... }
匹配规则: Nginx 会检查请求 URI 是否以 pattern 指定的字符串开头。如果请求 URI 的开头部分与 pattern 完全匹配，那么就认为这个 location 块是一个潜在的匹配项。
特点:
- pattern 是一个普通的字符串，不包含任何正则表达式特殊字符。
- 匹配过程是按照字符串进行比较。
- Nginx 会尝试找到所有可能的前缀匹配项，并选择其中最长的那个作为候选。
- location / 是一个特殊的前缀匹配，它匹配所有请求，通常用作最终的 fallback。

示例:

“`nginx
server {
listen 80;
server_name example.com;

location /images/ {
    # 处理所有以 /images/ 开头的请求
    root /data/www; # 例如，请求 /images/a.png 会查找 /data/www/images/a.png
}

location /css/ {
    # 处理所有以 /css/ 开头的请求
    root /data/www;
}

location / {
    # 处理所有其他请求
    root /data/www;
}

}
“`

请求 /images/logo.png：会匹配 location /images/。
请求 /css/style.css：会匹配 location /css/。
请求 /about：会匹配 location /。
请求 /images/static/photo.jpg：会匹配 location /images/，因为 /images/static/photo.jpg 以 /images/ 开头。
请求 /index.html：会匹配 location /。

注意点: 前缀匹配会寻找最长的匹配项。这是它与正则表达式匹配的一个重要区别。

2.2 精确匹配 (Exact Matching)

精确匹配用于对特定的、完整的 URI 进行匹配。它使用 = 修饰符。

语法:
nginx location = pattern { ... }
匹配规则: 只有当请求 URI 完全等于 pattern 指定的字符串时，这个 location 块才会被匹配。
特点:
- 匹配过程非常快速，因为 Nginx 只需要进行简单的字符串比较。
- 如果找到一个精确匹配的 location 块，Nginx 会立即停止搜索，并使用这个块来处理请求。这是优先级最高的匹配类型。
- 通常用于处理特定的入口点，例如 /login、/register 等，可以避免不必要的进一步匹配检查，提高效率。

示例:

“`nginx
server {
listen 80;
server_name example.com;

location = /login {
    # 只处理精确匹配 /login 的请求
    proxy_pass http://auth_server;
}

location / {
    # 处理所有其他请求
    root /data/www;
}

}
“`

请求 /login：会匹配 location = /login。
请求 /login/：不会匹配 location = /login，会匹配 location /。
请求 /register：不会匹配 location = /login，会匹配 location /。

2.3 正则表达式匹配 (Regular Expression Matching)

正则表达式匹配提供了更灵活的模式匹配能力，可以匹配符合特定规则的一类 URI。它使用 ~ 或 ~* 修饰符。

语法:
nginx location ~ pattern { ... } # 区分大小写的正则表达式匹配 location ~* pattern { ... } # 不区分大小写的正则表达式匹配
匹配规则: Nginx 会尝试将请求 URI 与 pattern 指定的正则表达式进行匹配。
特点:
- pattern 是一个标准的正则表达式。
- ~ 进行区分大小写的匹配。
- ~* 进行不区分大小写的匹配。
- 正则表达式匹配的优先级低于精确匹配和带有 ^~ 的前缀匹配，但高于普通前缀匹配。
- 如果多个正则表达式 location 块都能匹配请求 URI，Nginx 将使用配置中 第一个 找到的匹配项。这是与前缀匹配选择最长匹配项的一个重要区别。

示例:

“`nginx
server {
listen 80;
server_name example.com;

location ~ \.(jpg|jpeg|png|gif)$ {
    # 区分大小写匹配以 .jpg, .jpeg, .png, .gif 结尾的请求
    root /data/images;
}

location ~* \.(html|htm)$ {
    # 不区分大小写匹配以 .html 或 .htm 结尾的请求
    root /data/html;
}

location / {
    # 处理所有其他请求
    root /data/www;
}

}
“`

请求 /images/photo.jpg：会匹配 location ~ \.(jpg|jpeg|png|gif)$。
请求 /index.HTML：会匹配 location ~* \.(html|htm)$。
请求 /scripts/app.js：不会匹配上面的正则表达式，会匹配 location /。
请求 /FILES/document.GIF：会匹配 location ~ \.(jpg|jpeg|png|gif)$ (如果 ~* 在前面，则匹配 ~*）。

关于正则表达式: 正则表达式是强大的工具，但理解其语法需要额外的学习。在 Nginx 配置中，常见的用途包括匹配文件扩展名、路径模式等。一些常用的正则表达式元字符：
* .: 匹配除换行符外的任意单个字符。
* *: 匹配前一个字符零次或多次。
* +: 匹配前一个字符一次或多次。
* ?: 匹配前一个字符零次或一次。
* ^: 匹配字符串的开始。
* $: 匹配字符串的结束。
* |: 或运算符，匹配左边或右边的模式。
* (): 分组。
* []: 字符集，匹配方括号内的任意一个字符。
* \: 转义特殊字符。

注意: 正则表达式匹配的顺序很重要，Nginx 会按照它们在配置文件中出现的顺序进行检查。

2.4 带有 `^~` 修饰符的前缀匹配

^~ 修饰符用于指定一个普通的前缀匹配。它的特殊之处在于，如果 Nginx 找到了一个带有 ^~ 修饰符的最长前缀匹配，它会 立即停止 进一步的正则表达式匹配检查，并使用这个 location 块来处理请求。

语法:
nginx location ^~ pattern { ... }
匹配规则: Nginx 会进行前缀匹配，并选择最长的一个。如果这个最长前缀匹配带有 ^~ 修饰符，则优先使用它。
特点:
- 它结合了前缀匹配的简洁性（不需要写复杂的正则表达式）和优先级的提升（阻止后续的正则表达式匹配）。
- 通常用于指定某个目录下的请求应该优先使用前缀匹配规则处理，而不受可能存在的全局正则表达式规则的影响。例如，将 /static/ 目录下的请求直接按文件路径处理，即使有匹配文件扩展名的全局正则表达式。

示例:

“`nginx
server {
listen 80;
server_name example.com;

location ^~ /static/ {
    # 优先处理所有以 /static/ 开头的请求
    # 如果匹配到这个块，将不再进行下面的正则表达式匹配
    root /data/static;
}

location ~ \.(css|js)$ {
    # 处理以 .css 或 .js 结尾的请求 (如果 ^~ /static/ 没有匹配到)
    # 注意：如果请求是 /static/style.css，则会被上面的 ^~ 块处理，而不会走到这里
    root /data/assets;
}

location / {
    # 处理所有其他请求
    root /data/www;
}

}
“`

请求 /static/css/style.css：最长前缀匹配是 /static/。因为 /static/ 带有 ^~，Nginx 立即使用 location ^~ /static/ 来处理，即使它也匹配 location ~ \.(css|js)$。
请求 /scripts/app.js：不匹配 ^~ /static/。它匹配 location ~ \.(css|js)$，因此使用这个块。
请求 /images/photo.png：不匹配 ^~ /static/ 和 ~ \.(css|js)$，匹配 location /。

^~ 是理解 Nginx location 匹配顺序的关键之一。

3. `location` 匹配的优先级和顺序

理解 Nginx 如何在多个 location 块中选择一个来处理请求，是掌握 location 配置的核心。当一个请求 URI 到达时，Nginx 会按照一个特定的算法流程来决定使用哪个 location 块。这个流程结合了不同匹配类型的优先级和规则：

Nginx location 匹配流程 (简化版):

精确匹配 (=): Nginx 首先检查是否存在任何带有 = 修饰符的 location 块与请求 URI 完全匹配。
- 如果找到了一个精确匹配，Nginx 会立即选择这个块，停止搜索，并执行其中的指令。
- 如果没有找到精确匹配，Nginx 会继续下一步。
前缀匹配的查找 (普通 / 和 ^~): Nginx 会遍历所有不带正则表达式修饰符 (~, ~*) 的 location 块（包括普通前缀和 ^~ 前缀）。它会找出所有与请求 URI 的开头部分匹配的 location 块，并从中选出最长的那个前缀匹配项。
- 例如，对于请求 /app/users/profile，如果存在 location /app/ 和 location /app/users/，最长前缀匹配就是 location /app/users/。
- 此时 Nginx 会记住这个最长的非正则表达式前缀匹配项。
^~ 前缀匹配的检查: Nginx 检查在步骤 2 中找到的 最长前缀匹配项 是否带有 ^~ 修饰符。
- 如果带有 ^~ 修饰符，Nginx 会立即选择这个块，停止搜索（不再进行正则表达式匹配），并执行其中的指令。
- 如果不带 ^~ 修饰符，Nginx 会保留这个最长前缀匹配项作为一个 候选项，并继续下一步进行正则表达式匹配检查。
正则表达式匹配 (~, ~*): 如果在步骤 1 或步骤 3 没有停止搜索，Nginx 会开始按 它们在配置文件中出现的顺序 检查所有带有 ~ 或 ~* 修饰符的 location 块。
- Nginx 会找到第一个与请求 URI 匹配的正则表达式 location 块。
- 如果找到了这样一个正则表达式匹配，Nginx 会选择 第一个匹配到的 这个块，停止搜索，并执行其中的指令。
- 如果遍历了所有的正则表达式 location 块，但没有一个匹配请求 URI，Nginx 会继续下一步。
使用最长前缀匹配 (Fallback): 如果经过前面的步骤（精确匹配、^~ 前缀匹配、正则表达式匹配）都没有找到并停止搜索的 location 块，Nginx 会最终使用在步骤 2 中找到并保留的 最长前缀匹配项 来处理请求。这包括了 location / 作为最终的默认 fallback。

总结优先级（从高到低）：

= 精确匹配: 如果匹配到，立即停止。
^~ 前缀匹配: 如果最长前缀匹配带有 ^~，立即停止（并跳过所有正则表达式匹配）。
~ 或 ~* 正则表达式匹配: 按配置顺序，第一个匹配到的获胜（如果前面没有被 = 或 ^~ 停止）。
普通前缀匹配 (包括 /): 在没有任何精确匹配、带 ^~ 的前缀匹配或正则表达式匹配成功时，使用之前找到的最长普通前缀匹配项。

核心记住:

= 最快，优先级最高，精确匹配一个 URI。
^~ 阻止正则表达式匹配，优先处理特定前缀路径。
正则表达式 (~, ~*) 按顺序检查，第一个匹配的生效。
普通前缀 (/) 选择最长的那个，并在前面所有匹配都失败后才使用它（除非它带有 ^~）。

4. 结合实例理解匹配顺序

让我们通过一个更复杂的例子来模拟 Nginx 的匹配过程：

“`nginx
server {
listen 80;
server_name example.com;

# Rule 1: Exact match for login page
location = /login {
    return 200 "This is the login page.";
}

# Rule 2: Priority prefix for static files, disable regex check
location ^~ /static/ {
    root /data/static;
    return 200 "Serving static file from ^~ block.";
}

# Rule 3: Regex for images (case-insensitive)
location ~* \.(png|jpg|jpeg|gif)$ {
    root /data/images;
    return 200 "Serving image from regex block.";
}

# Rule 4: Regex for documents (case-sensitive)
location ~ \.(doc|docx|pdf)$ {
    root /data/docs;
    return 200 "Serving document from regex block.";
}

# Rule 5: General prefix match for admin area
location /admin/ {
    return 200 "Accessing admin area from /admin/ prefix block.";
}

# Rule 6: General fallback for all other requests
location / {
    root /data/www;
    return 200 "Serving content from the root / block.";
}

}
“`

现在我们模拟几个请求，看看它们会匹配哪个 location 块：

请求 /login:
- 检查精确匹配：location = /login 完全匹配 /login。
- 结果：匹配 Rule 1 (location = /login)。Nginx 停止搜索。返回 “This is the login page.”。
请求 /static/css/style.css:
- 检查精确匹配：没有 = 匹配 /static/css/style.css。
- 查找前缀匹配：
  - /static/css/style.css 以 /static/ 开头 (Rule 2)。
  - /static/css/style.css 以 /admin/ 开头 (Rule 5) – No.
  - /static/css/style.css 以 / 开头 (Rule 6).
  - 最长前缀匹配是 /static/ (Rule 2)。
- 检查最长前缀 (/static/) 是否带 ^~：是的，Rule 2 (location ^~ /static/) 带有 ^~。
- 结果：匹配 Rule 2 (location ^~ /static/)。Nginx 立即停止搜索（跳过 regex）。返回 “Serving static file from ^~ block.”。
请求 /images/photo.PNG:
- 检查精确匹配：没有。
- 查找前缀匹配：
  - /images/photo.PNG 以 /static/ 开头 – No.
  - /images/photo.PNG 以 /admin/ 开头 – No.
  - /images/photo.PNG 以 / 开头 (Rule 6).
  - 最长前缀匹配是 / (Rule 6)。
- 检查最长前缀 (/) 是否带 ^~：否。
- 保留 Rule 6 作为候选项，继续检查正则表达式。
- 检查正则表达式 (按顺序):
  - Rule 3 (location ~* \.(png|jpg|jpeg|gif)$): /images/photo.PNG 不区分大小写 匹配 .PNG。匹配成功。
- 结果：匹配 Rule 3 (location ~* \.(png|jpg|jpeg|gif)$)。Nginx 停止搜索。返回 “Serving image from regex block.”。
请求 /mydocs/report.DOCX:
- 检查精确匹配：没有。
- 查找前缀匹配：
  - /mydocs/report.DOCX 以 /static/ 开头 – No.
  - /mydocs/report.DOCX 以 /admin/ 开头 – No.
  - /mydocs/report.DOCX 以 / 开头 (Rule 6).
  - 最长前缀匹配是 / (Rule 6)。
- 检查最长前缀 (/) 是否带 ^~：否。
- 保留 Rule 6 作为候选项，继续检查正则表达式。
- 检查正则表达式 (按顺序):
  - Rule 3 (location ~* \.(png|jpg|jpeg|gif)$): /mydocs/report.DOCX 不区分大小写 不匹配这些扩展名。
  - Rule 4 (location ~ \.(doc|docx|pdf)$): /mydocs/report.DOCX 区分大小写 不匹配 .DOCX (因为是大写)。
- 结果：没有正则表达式匹配成功。Nginx 使用之前保留的最长前缀匹配项，即 Rule 6 (location /)。返回 “Serving content from the root / block.”。
请求 /admin/users:
- 检查精确匹配：没有。
- 查找前缀匹配：
  - /admin/users 以 /static/ 开头 – No.
  - /admin/users 以 /admin/ 开头 (Rule 5).
  - /admin/users 以 / 开头 (Rule 6).
  - 最长前缀匹配是 /admin/ (Rule 5)。
- 检查最长前缀 (/admin/) 是否带 ^~：否。
- 保留 Rule 5 作为候选项，继续检查正则表达式。
- 检查正则表达式 (按顺序):
  - Rule 3 (location ~* \.(png|jpg|jpeg|gif)$): /admin/users 不匹配。
  - Rule 4 (location ~ \.(doc|docx|pdf)$): /admin/users 不匹配。
- 结果：没有正则表达式匹配成功。Nginx 使用之前保留的最长前缀匹配项，即 Rule 5 (location /admin/)。返回 “Accessing admin area from /admin/ prefix block.”。
请求 /about:
- 检查精确匹配：没有。
- 查找前缀匹配：
  - /about 以 /static/ 开头 – No.
  - /about 以 /admin/ 开头 – No.
  - /about 以 / 开头 (Rule 6).
  - 最长前缀匹配是 / (Rule 6)。
- 检查最长前缀 (/) 是否带 ^~：否。
- 保留 Rule 6 作为候选项，继续检查正则表达式。
- 检查正则表达式 (按顺序):
  - Rule 3 (location ~* \.(png|jpg|jpeg|gif)$): /about 不匹配。
  - Rule 4 (location ~ \.(doc|docx|pdf)$): /about 不匹配。
- 结果：没有正则表达式匹配成功。Nginx 使用之前保留的最长前缀匹配项，即 Rule 6 (location /)。返回 “Serving content from the root / block.”。

这个例子清楚地展示了 location = 的最高优先级，^~ 如何阻止正则表达式检查，正则表达式按顺序匹配，以及普通前缀匹配（包括 /）如何在前面规则都失败后作为最终候选项被使用。

5. 特殊的前缀 `location /`

location / 是一个特殊的前缀匹配。因为所有请求 URI 都以 / 开头，所以 location / 块总是能匹配任何请求（除非请求 URI 是空的，这实际上不可能）。根据 Nginx 的匹配规则，location / 作为前缀匹配，它的长度是 1。除非有更长的前缀匹配或者正则表达式匹配成功，否则 location / 会成为最终被选中的 location 块。

因此，location / 通常被用作 默认的、最后的 fallback 块。你可以在这里放置处理大多数请求的通用配置，或者作为错误处理的最终目的地。

6. 常见陷阱与最佳实践

正则表达式顺序: 当使用多个正则表达式 location 时，务必注意它们在配置文件中的顺序。排在前面的如果匹配成功，后面的将不会被检查。这可能导致意想不到的行为。将更具体、更常用或优先级更高的正则表达式放在前面。
前缀与正则表达式的混淆: 明确理解前缀匹配是选最长，而正则表达式匹配是选 第一个。不要混淆这两种逻辑。
^~ 的重要性: 使用 ^~ 可以提高性能，因为它避免了不必要的正则表达式检查。如果某个目录（例如 /static/）下的文件你确定只想通过前缀匹配来处理，而不想受全局的 .jpg 或 .css 正则表达式影响，那么一定要使用 ^~。
精确匹配 (=): 对于少量特定 URI，使用 = 可以显著提高匹配速度，因为 Nginx 找到精确匹配后立即停止搜索。
斜杠 (/) 的处理: 请求 URI 和 location pattern 中斜杠的使用需要注意。
- 请求 URI 以 / 开头。
- location /foo 匹配 /foo 但不匹配 /foo/ 或 /foobar。
- location /foo/ 匹配 /foo/、/foo/bar，但不匹配 /foo。
- location = /foo 只匹配 /foo。
- location = /foo/ 只匹配 /foo/。
  大多数 Web 框架或应用会规范化 URI (例如，移除末尾斜杠)，但在 Nginx 层面，需要根据实际的请求 URI 路径来编写匹配规则。通常建议 location 块的末尾斜杠与你期望匹配的 URI 路径的末尾斜杠保持一致或考虑两种情况。例如，location /app/ { ... } 会匹配 /app/ 和 /app/anything。如果也想匹配 /app，可能需要额外的 location = /app { ... } 或者在应用层面处理重定向。
测试配置: 修改 Nginx 配置后，务必使用 nginx -t 命令检查配置文件的语法是否正确，然后使用 nginx -s reload 安全地重新加载配置，避免服务中断。
日志调试: 如果不确定哪个 location 块被匹配，可以在每个 location 块内添加一个日志指令，例如 error_log /var/log/nginx/debug.log debug; (需要 Nginx 编译时开启 debug 模块，并且在 http 块设置 debug_points info;) 或简单的 add_header X-Matched-Location "location_name"; 返回到客户端，或者在 error_log 中输出变量，例如 error_log /var/log/nginx/error.log info "Matched location: $request_uri -> $request_filename";。

7. 常见 `location` 使用场景示例

理解 location 匹配规则后，可以更灵活地配置 Nginx 来实现各种功能：

服务静态文件:
“`nginx
location /static/ {
root /data/www/; # 匹配 /static/a.css 会查找 /data/www/static/a.css
expires 30d;
}

location ~* .(jpg|png)$ {
root /data/images; # 匹配 /images/a.jpg 会查找 /data/images/a.jpg
expires 7d;
}
`` 这里/static/` 使用前缀匹配，而图片文件使用正则表达式匹配，可以根据具体需求设置不同的过期时间和根目录。
反向代理到后端应用:
“`nginx
location /api/ {
proxy_pass http://backend_api; # 将所有 /api/ 开头的请求转发到 backend_api
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}

location /app/ {
proxy_pass http://node_app; # 将所有 /app/ 开头的请求转发到 node_app
}

location = /login {
proxy_pass http://auth_server; # 精确匹配 /login 请求到认证服务
}
“`
可以根据 URL 路径将不同的请求转发到不同的后端服务。
重定向:
“`nginx
location = /old/path {
return 301 /new/path; # 精确匹配 /old/path，永久重定向到 /new/path
}

location /images/old/ {
rewrite ^/images/old/(.*)$ /images/new/$1 permanent; # 重写 /images/old/… 到 /images/new/…
}
`` 使用return或rewrite指令在location` 块内实现 URL 重定向。
禁止访问:
“`nginx
location ~ /.ht {
deny all; # 禁止访问所有以 .ht 开头的文件（如 .htaccess）
}

location /private/ {
deny all; # 禁止访问 /private/ 目录及其子目录
}
`` 通过deny all;` 指令阻止对某些路径的访问。

8. 总结表格

为了方便快速回顾，这里列出 location 匹配类型的优先级和特点：

修饰符	类型	匹配方式	优先级	匹配规则	示例 Pattern	说明
`=`	精确匹配	完全相等	最高	URI 完全等于 Pattern，匹配到即停止	`/login`	用于特定、完整的 URI 匹配，速度最快。
`^~`	前缀匹配 (优先)	前缀匹配，阻止正则表达式检查	高	URI 以 Pattern 开头，且该 Pattern 是最长匹配，匹配到即停止，并跳过 Regex	`/static/`	强制对特定前缀路径使用前缀匹配规则，忽略 Regex。
`~`	正则表达式	区分大小写正则表达式	中	URI 与 Pattern (Regex) 匹配，第一个匹配的 Regex 生效	`\.(png\|jpg)$`	灵活匹配一类 URI，区分大小写。
`~*`	正则表达式	不区分大小写正则表达式	中	URI 与 Pattern (Regex) 匹配，第一个匹配的 Regex 生效	`\.(html\|htm)$`	灵活匹配一类 URI，不区分大小写。
(无)	前缀匹配	前缀匹配	低	URI 以 Pattern 开头，选择最长匹配项，作为 Regex 失败后的 fallback	`/images/`, `/`	常用于匹配目录或作为默认 fallback (`/`)。

匹配顺序总结: = -> ^~ (最长前缀) -> ~/~* (按顺序第一个) -> 无修饰符 (最长前缀)

9. 结语

Nginx 的 location 匹配规则是其灵活路由能力的基础。虽然初看起来可能有些复杂，特别是优先级和不同匹配类型之间的交互，但一旦掌握了它的匹配算法（精确匹配优先，然后是带 ^~ 的最长前缀，接着是按顺序的正则表达式，最后是不带 ^~ 的最长前缀），你就可以自信地编写出高效且符合预期的 Nginx 配置。

记住，实践是最好的老师。尝试不同的 location 配置组合，使用 nginx -t 检查语法，并通过访问不同的 URL 来验证匹配行为。理解了这套规则，你就能更好地利用 Nginx 来构建强大的 Web 服务和应用架构。希望这篇文章能帮助你彻底理解 Nginx 的 location 匹配规则，真正做到“看这篇就够了”！

Nginx location 匹配规则：看这篇就够了 – wiki基地

Nginx location 匹配规则：看这篇就够了

1. `location` 指令的基本语法

2. `location` 的主要匹配类型

2.1 前缀匹配 (Prefix Matching)

2.2 精确匹配 (Exact Matching)

2.3 正则表达式匹配 (Regular Expression Matching)

2.4 带有 `^~` 修饰符的前缀匹配

3. `location` 匹配的优先级和顺序

4. 结合实例理解匹配顺序

5. 特殊的前缀 `location /`

6. 常见陷阱与最佳实践

7. 常见 `location` 使用场景示例

8. 总结表格

9. 结语

发表评论取消回复

Nginx location 匹配规则：看这篇就够了

1. location 指令的基本语法

2. location 的主要匹配类型

2.1 前缀匹配 (Prefix Matching)

2.2 精确匹配 (Exact Matching)

2.3 正则表达式匹配 (Regular Expression Matching)

2.4 带有 ^~ 修饰符的前缀匹配

3. location 匹配的优先级和顺序

4. 结合实例理解匹配顺序

5. 特殊的前缀 location /

6. 常见陷阱与最佳实践

7. 常见 location 使用场景示例

8. 总结表格

9. 结语

发表评论 取消回复

1. `location` 指令的基本语法

2. `location` 的主要匹配类型

2.4 带有 `^~` 修饰符的前缀匹配

3. `location` 匹配的优先级和顺序

5. 特殊的前缀 `location /`

7. 常见 `location` 使用场景示例

发表评论取消回复