Nginx Location 匹配规则：从入门到精通

Nginx 是一个高性能的 HTTP 和反向代理服务器，也是一个 IMAP/POP3/SMTP 代理服务器。它的配置灵活强大，其中 location 指令是 Nginx 配置中最核心、最常用，也是最容易让人感到困惑的部分之一。理解 location 的匹配规则，是掌握 Nginx 配置的关键。

本文将从零开始，详细解析 Nginx location 指令的语法、不同匹配类型、优先级顺序以及一些高级用法和最佳实践，帮助你彻底掌握 Nginx 的请求路由机制。

第一部分：初识 Location – 它是什么以及为什么重要？

在 Nginx 的配置文件中，server 块用于定义一个虚拟主机（或称服务器），它监听特定的 IP 地址和端口。而 location 块则嵌套在 server 块内部，它的主要作用是根据客户端请求的 URI（统一资源标识符）来决定如何处理该请求。

简单来说，location 指令就是告诉 Nginx：“对于满足某个特定规则的 URI 请求，请按照这个 location 块里的指令去处理。”

例如，你可能希望：
* / 路径的请求由你的主应用处理。
* /static/ 路径下的请求直接从文件系统提供静态文件。
* /api/ 路径下的请求转发（代理）给后端的 API 服务器。
* /images/ 路径下的 JPG 和 PNG 图片请求设置特定的缓存策略。

所有这些路由和处理逻辑，都是通过 location 指令来实现的。因此，location 指令是 Nginx 进行请求分发、动静态分离、负载均衡、缓存控制、访问控制等功能的基础。

一个基本的 location 块的结构如下：

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

location / {
    # 如何处理根路径请求的指令
    root /usr/share/nginx/html;
    index index.html index.htm;
}

location /static/ {
    # 如何处理 /static/ 路径请求的指令
    alias /path/to/static/files/; # 或者使用 root
    expires 30d;
}

# 更多 location 块...

}
“`

理解 location 的关键在于理解 Nginx 如何根据请求的 URI，在众多的 location 块中选择唯一的一个来执行。这个选择过程遵循一套特定的匹配规则和优先级顺序。

第二部分：Location 匹配类型 – 看懂那些符号

location 指令后面跟着一个可选的修饰符（Modifier）和一个用于匹配 URI 的模式（Pattern）。不同的修饰符决定了不同的匹配方式。

location [modifier] pattern { ... }

让我们逐一看看这些修饰符和模式类型：

1. 前缀匹配（Prefix Matching） – 无修饰符

这是最简单也是最常用的匹配方式。如果 location 后面没有修饰符，则表示进行前缀匹配。Nginx 会检查请求的 URI 是否以指定的模式字符串开头。

语法: location pattern { ... }
工作方式: 匹配以 pattern 开头的 URI。
示例:
nginx location /documents/ { # 匹配 /documents/，/documents/file.html，/documents/2023/report.pdf 等 # 但不匹配 /mydocuments/ }
特点: Nginx 会查找所有前缀匹配的 location，并选择匹配度最长的那个。这是优先级规则中的重要一环。

2. 精确匹配（Exact Matching） – 修饰符 `=`

使用 = 修饰符表示进行精确匹配。只有当请求的 URI 与指定的模式字符串完全一致时，这个 location 块才会被选中。

语法: location = pattern { ... }
工作方式: 匹配与 pattern 完全一致的 URI。
示例:
nginx location = /login { # 只匹配 /login 这个 URI # 不匹配 /login?user=... 或 /login/ }
特点: 精确匹配具有最高的优先级。如果 Nginx 找到了一个精确匹配，它会立即停止搜索其他 location，并使用这个块来处理请求。这对于处理特定的单一入口（如登录页、首页）非常高效。

3. 正则表达式匹配（Regular Expression Matching） – 修饰符 `~` 和 `~*`

正则表达式匹配提供了更灵活的匹配能力，可以根据复杂的模式来匹配 URI。Nginx 支持 Perl 兼容的正则表达式。

修饰符 ~: 表示区分大小写的正则表达式匹配。
- 语法: location ~ pattern { ... }
- 工作方式: 如果 URI 符合正则表达式 pattern，则匹配。匹配过程区分 URI 和 pattern 中字母的大小写。
- 示例:
  nginx location ~ \.(gif|jpg|png)$ { # 匹配以 .gif, .jpg, .png 结尾的 URI (区分大小写) # 例如: /images/photo.jpg 匹配 # 但 /images/PHOTO.JPG 不匹配 }
修饰符 ~*: 表示不区分大小写的正则表达式匹配。
- 语法: location ~* pattern { ... }
- 工作方式: 如果 URI 符合正则表达式 pattern，则匹配。匹配过程忽略 URI 和 pattern 中字母的大小写。
- 示例:
  nginx location ~* \.(gif|jpg|png)$ { # 匹配以 .gif, .jpg, .png 结尾的 URI (不区分大小写) # 例如: /images/photo.jpg 和 /images/PHOTO.JPG 都匹配 }
特点: 正则表达式匹配的优先级低于精确匹配和某些类型的前缀匹配。Nginx 会按照它们在配置文件中出现的顺序来检查正则表达式 location，一旦找到第一个匹配项，就会使用它。

4. 优先前缀匹配（Preferential Prefix Matching） – 修饰符 `^~`

^~ 修饰符结合了前缀匹配和优先级的概念。它执行前缀匹配，但如果找到一个匹配项，Nginx 就会停止搜索 正则表达式 location，转而直接使用这个 ^~ 匹配块。

语法: location ^~ pattern { ... }
工作方式: 进行前缀匹配。如果匹配成功，并且这是最长的匹配前缀（或者 Nginx 在检查常规前缀匹配时选择了它），则跳过后续的正则表达式匹配阶段，直接使用这个 location 块。
示例:
“`nginx
location ^~ /static/ {
# 匹配以 /static/ 开头的 URI
# 例如: /static/css/style.css
# 如果请求是 /static/，即使后面有匹配的正则表达式，Nginx 也会优先使用这个块
}

location ~ .php$ {
# 处理 PHP 文件
}
`` 在这个例子中，如果请求是/static/image.php，尽管.php的正则匹配也可能匹配，但由于/static/的^~匹配到了，Nginx 会优先使用/static/这个location，而不会去检查.php` 的正则表达式。这对于快速处理静态文件非常有用。
特点: 它的优先级高于正则表达式匹配，但低于精确匹配。它能防止对特定前缀的请求进入开销较大的正则表达式匹配阶段，从而提高性能。

总结不同匹配类型的特点和用途：

修饰符	类型	描述	优先级	典型用途
`=`	精确匹配	URI 必须与模式完全一致	最高	精确的特定路径，如首页、登录页
`^~`	优先前缀匹配	URI 以模式开头，匹配成功则跳过后续正则匹配阶段	高于正则，低于精确	快速处理特定路径下的资源（如静态文件）
`~`	正则表达式匹配	URI 符合区分大小写的正则表达式模式	低于 `=` 和 `^~`	复杂模式匹配，如文件类型、特定参数等（区分大小写）
`~*`	正则表达式匹配	URI 符合不区分大小写的正则表达式模式	低于 `=` 和 `^~`	文件类型等（不区分大小写）
(无)	前缀匹配	URI 以模式开头。Nginx 会选择所有前缀匹配中匹配度最长的那个	低于 `=` 和 `^~`	目录匹配，默认处理
`/`	特殊前缀匹配	匹配任何 URI。作为所有匹配失败后的默认处理，优先级最低（但总是匹配）	最低（除非无其他匹配）	网站的默认处理入口

这里的 / 作为一种特殊的前缀匹配，它能匹配任何 URI，通常用作最后的备用方案（fallback）。

第三部分：Location 匹配优先级 – Nginx 如何做选择？

理解了不同的匹配类型后，更重要的是理解当存在多个 location 块都可能匹配某个 URI 时，Nginx 是如何决定使用哪一个的。Nginx 的匹配优先级遵循一个明确的顺序：

Nginx Location 匹配优先级顺序：

检查所有精确匹配 (=)： Nginx 会遍历所有使用 = 修饰符定义的 location 块。如果找到一个与请求 URI 完全一致的 location，则立即停止搜索，使用这个块来处理请求。这是最高优先级。
检查所有前缀匹配 (无修饰符或 ^~)： 如果没有找到精确匹配，Nginx 会继续检查所有使用无修饰符或 ^~ 修饰符定义的前缀匹配 location 块。Nginx 会找出所有匹配当前 URI 的前缀 location。
- 选择最长的前缀匹配： 在所有匹配的前缀 location 中，Nginx 会选择匹配度最长（即模式字符串最长）的那个。
- 判断是否为 ^~：
  - 如果被选中的最长前缀匹配使用了 ^~ 修饰符，那么 Nginx 会立即停止后续的正则表达式搜索阶段，直接使用这个 ^~ 块来处理请求。
  - 如果被选中的最长前缀匹配没有使用修饰符 (即普通前缀匹配)，Nginx 会记住这个最长前缀匹配块，但并不会立即使用它。它会继续进入下一个阶段：正则表达式匹配。
检查所有正则表达式匹配 (~ 和 ~*)： 如果步骤1没有精确匹配，并且步骤2选中的最长前缀匹配不是 ^~，Nginx 会按照它们在配置文件中定义的顺序，逐个检查所有的正则表达式 location 块。
- 使用第一个匹配的正则表达式： Nginx 会使用 第一个 匹配成功的正则表达式 location 来处理请求。找到第一个匹配项后，立即停止搜索后续的正则表达式 location。
使用之前记住的最长前缀匹配： 如果步骤3中没有找到任何匹配的正则表达式 location (或者在步骤2中没有找到任何前缀匹配，这种情况较少，因为 / 总是前缀匹配)，Nginx 就会使用在步骤2中记住的那个最长前缀匹配 location 来处理请求。如果连最长前缀匹配都没有（比如配置里一个前缀 location 都没有），则会使用根 / 的 location 块。

简化理解的流程：

先看有没有 精确匹配 =？有就用它，结束。
如果没有，找出 所有前缀匹配 中最长的那个。
这个 最长前缀 是 ^~ 吗？如果是，就用它，结束。
如果不是 ^~，或者压根没有前缀匹配，就开始从上往下检查 正则表达式 ~ 或 ~*。用 第一个匹配 的，结束。
如果所有正则表达式都没匹配上，就用之前找出的 最长前缀匹配。如果连前缀匹配都没有，就用 / （它总是最长前缀匹配，除非有比它更长的 /something/ 前缀，但 / 总是能匹配）。

示例解析：

假设有以下 location 配置：

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

location = / {
    # A - 精确匹配根路径
    return 200 "Exact match for /";
}

location / {
    # B - 默认前缀匹配，所有其他请求的备用
    return 200 "Prefix match for /";
}

location /documents/ {
    # C - 前缀匹配 /documents/
    return 200 "Prefix match for /documents/";
}

location ^~ /static/ {
    # D - 优先前缀匹配 /static/
    return 200 "Preferential prefix match for /static/";
}

location ~ \.(jpg|png)$ {
    # E - 正则匹配 .jpg 或 .png (区分大小写)
    return 200 "Regex match for jpg or png (case-sensitive)";
}

location ~* \.css$ {
    # F - 正则匹配 .css (不区分大小写)
    return 200 "Regex match for css (case-insensitive)";
}

}
“`

现在我们看几个请求 URI 会匹配哪个 location：

URI: /
- 检查精确匹配：location = / 匹配。
- 结果：匹配 location = / (A)。Nginx 停止搜索。
URI: /index.html
- 检查精确匹配：无 = 匹配 /index.html。
- 检查前缀匹配：
  - / (B) 匹配。
  - /documents/ (C) 不匹配。
  - /static/ (D) 不匹配。
  - 最长匹配前缀是 / (B)。它不是 ^~。记住 (B)，继续。
- 检查正则表达式：
  - ~ \.(jpg|png)$ (E) 不匹配。
  - ~* \.css$ (F) 不匹配。
  - 没有正则表达式匹配。
- 结果：使用之前记住的最长前缀匹配 / (B)。
URI: /documents/report.pdf
- 检查精确匹配：无。
- 检查前缀匹配：
  - / (B) 匹配。
  - /documents/ (C) 匹配。
  - /static/ (D) 不匹配。
  - 最长匹配前缀是 /documents/ (C)。它不是 ^~。记住 (C)，继续。
- 检查正则表达式：无匹配。
- 结果：使用之前记住的最长前缀匹配 /documents/ (C)。
URI: /static/js/script.js
- 检查精确匹配：无。
- 检查前缀匹配：
  - / (B) 匹配。
  - /documents/ (C) 不匹配。
  - /static/ (D) 匹配。
  - 最长匹配前缀是 /static/ (D)。
- 这是 ^~ 匹配。
- 结果：匹配 location ^~ /static/ (D)。Nginx 停止搜索正则表达式。
URI: /images/photo.JPG
- 检查精确匹配：无。
- 检查前缀匹配：
  - / (B) 匹配。
  - /documents/ (C) 不匹配。
  - /static/ (D) 不匹配。
  - 最长匹配前缀是 / (B)。它不是 ^~。记住 (B)，继续。
- 检查正则表达式：
  - ~ \.(jpg|png)$ (E) 不匹配 (大小写不符)。
  - ~* \.css$ (F) 不匹配。
  - 没有正则表达式匹配。
- 结果：使用之前记住的最长前缀匹配 / (B)。
- 注意： 如果请求是 /images/photo.jpg，则会匹配 ~ \.(jpg|png)$ (E)，因为它是第一个匹配的正则表达式。正则表达式的顺序很重要！
URI: /css/style.CSS
- 检查精确匹配：无。
- 检查前缀匹配：
  - / (B) 匹配。
  - /documents/ (C) 不匹配。
  - /static/ (D) 不匹配。
  - 最长匹配前缀是 / (B)。它不是 ^~。记住 (B)，继续。
- 检查正则表达式：
  - ~ \.(jpg|png)$ (E) 不匹配。
  - ~* \.css$ (F) 匹配。
  - 这是第一个匹配的正则表达式。
- 结果：匹配 location ~* \.css$ (F)。

通过这些例子，可以看出 Nginx 的 location 匹配是一个多阶段的过程，优先级和配置顺序（对于正则表达式）共同决定了最终的选择。

第四部分：常用指令与 Location 块的组合

location 块不仅仅用于匹配 URI，更重要的是在块内部定义如何处理匹配到的请求。一些最常用的指令包括：

root: 定义查找文件的根目录。Nginx 会将 root 路径与 URI 拼接起来形成完整的文件路径。
nginx location /static/ { root /var/www/html; # 请求 /static/css/style.css 会尝试访问 /var/www/html/static/css/style.css }
alias: 也定义查找文件的路径，但更灵活。alias 会用指定的路径替换掉 location 匹配的部分 URI。通常用于 / 结尾的 location 块。
nginx location /static/ { alias /path/to/static/files/; # 请求 /static/css/style.css 会尝试访问 /path/to/static/files/css/style.css # alias 路径通常也以 / 结尾 }
注意 root 和 alias 的区别： root 是拼接，alias 是替换。在一个 / 结尾的 location 中，使用 alias 更常见，以避免路径重复。但在非 / 结尾的 location (如 location /static) 或精确匹配 (location = /static) 中，使用 root 或 alias 可能会导致意外的文件路径，需谨慎。最安全的做法是在 / 结尾的 location 中使用 alias，在其他情况（尤其是正则匹配）中使用 root。
index: 定义目录请求时默认的文件名（如 index.html）。
nginx location / { root /usr/share/nginx/html; index index.html index.htm; # 如果请求 /，且 /usr/share/nginx/html 存在，Nginx 会尝试返回 /usr/share/nginx/html/index.html 或 /usr/share/nginx/html/index.htm }
try_files: 按顺序检查文件是否存在，并使用第一个找到的文件进行处理，或者执行一个内部重定向。
nginx location / { root /usr/share/nginx/html; try_files $uri $uri/ /index.html =404; # 尝试访问 URI 对应的文件 # 如果文件不存在，尝试访问 URI 对应的目录下的 index 文件 # 如果目录也不存在或没有 index 文件，内部重定向到 /index.html # 如果 /index.html 也不存在，返回 404 错误 }
try_files 是处理单页应用 (SPA) 路由或友好的 404 页面的常用指令。
proxy_pass: 将请求转发给另一个服务器（通常是后端应用服务器）。
“`nginx
location /api/ {
proxy_pass http://backend_server;
# 将 /api/something 的请求转发到 http://backend_server/api/something
}

location /app/ {
proxy_pass http://another_server/; # 注意这里的斜杠
# 将 /app/page 的请求转发到 http://another_server/page
# 如果 proxy_pass 的 URL 后面有路径（无论有没有斜杠），Nginx 会用 proxy_pass 后面的路径替换掉 location 匹配的部分。
# 如果 proxy_pass 的 URL 后面没有路径（只有服务器地址），Nginx 会将 location 匹配的部分保留并附加到 proxy_pass 地址后面。
}
* `rewrite`: 使用正则表达式重写 URI。优先级比较高，会在 location 匹配 *之后*，请求处理 *之前* 执行，可能会影响到 `try_files` 或 `proxy_pass`。nginx
location /old-path/ {
rewrite ^/old-path/(.*)$ /new-path/$1 permanent; # 永久重定向
}
* `return`: 直接返回指定的 HTTP 状态码和可选的响应体。优先级很高。nginx
location /forbidden {
return 403 “Access Denied”;
}
* `allow`, `deny`: 基于 IP 地址控制访问。nginx
location /admin/ {
allow 192.168.1.0/24;
deny all;
}
“`

这些指令在 location 块中协同工作，共同定义了请求的处理流程。

第五部分：高级话题与最佳实践

1. 根路径 `/` 的特殊性

location / 是最通用的前缀匹配，它可以匹配任何 URI。在匹配优先级规则中，它扮演着“最后一道防线”的角色。如果所有精确匹配、优先前缀匹配和正则表达式匹配都没有命中，Nginx 就会使用 location / 块来处理请求。因此，几乎所有的 Nginx 配置都包含一个 location / 块，用于定义默认行为，例如提供网站首页或返回 404 错误。

nginx location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ =404; }

2. 利用 `^~` 优化静态文件服务

对于静态文件（如 CSS、JS、图片等），通常建议使用 ^~ 前缀匹配来处理，以提高效率。这样可以确保 Nginx 在匹配到 /static/、/images/ 等路径时，立即停止搜索正则表达式，避免不必要的正则匹配开销。

“`nginx
location ^~ /static/ {
alias /opt/website/static/;
expires 30d; # 设置浏览器缓存过期时间
access_log off; # 静态文件通常不需要记录访问日志
}

location ~ .(php|jsp)$ {
# 处理动态请求，这会在 ^~ 匹配之后检查
proxy_pass …;
}
“`

3. 正则表达式的顺序很重要

对于正则表达式 location (~ 或 ~*)，Nginx 是按照它们在配置文件中出现的顺序进行匹配的。这意味着，如果一个 URI 同时匹配多个正则表达式 location，只有第一个匹配的会被使用。因此，应该将更具体或更常用的正则表达式放在前面。

“`nginx

错误的顺序示例

location ~ .html$ { # 匹配所有 HTML
# 处理 HTML
}
location ~ /specific/page.html$ { # 匹配一个特定的 HTML
# 特殊处理
}

如果请求是 /specific/page.html，它会先匹配到第一个 location，第二个 location 永远不会被使用。

正确的顺序示例

location ~ /specific/page.html$ { # 匹配一个特定的 HTML
# 特殊处理
}
location ~ .html$ { # 匹配所有 HTML
# 处理 HTML (除了前面特殊处理的那个)
}
“`

4. 避免复杂的嵌套 Location

Nginx 允许在 location 块内部嵌套 location 块。然而，这会使得配置变得复杂且难以理解和维护。在大多数情况下，可以通过扁平化的 location 结构和合理的优先级设置来达到相同的目的。尽量避免使用嵌套 location。

5. 使用命名 Location (`@`)

命名 location 以 @ 符号开头，它们不用于处理正常的客户端请求。它们主要用于内部重定向，例如在使用 try_files 或 error_page 指令时。

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

location / {
    root /usr/share/nginx/html;
    try_files $uri $uri/ @fallback;
}

location @fallback {
    # 当 try_files 找不到文件时，内部重定向到这里
    proxy_pass http://backend;
}

error_page 404 = @404_page;

location @404_page {
    # 当返回 404 错误时，内部重定向到这里
    root /usr/share/nginx/html;
    internal; # 标记为内部使用，外部无法直接访问
}

}
`` 命名location` 有其特定的用途，可以使配置更清晰，尤其是在错误处理和内部重定向方面。

6. Location 和 Rewrite 的交互

rewrite 指令的执行优先级相对较高。在 Nginx 确定了匹配的 location 块之后，但在执行块内的其他大部分指令（如 proxy_pass, root, index）之前，会先执行 rewrite 指令。如果 rewrite 规则导致 URI 发生变化，Nginx 会使用新的 URI 重新进行 location 匹配过程（最多10次循环）。这可能会导致预期的 location 匹配失败，或者进入一个不同的 location 块。因此，在使用 rewrite 时需要非常小心，理解它对 location 匹配的影响。

推荐的做法是尽可能少用 rewrite 进行复杂的内部跳转，多使用 try_files 或在应用层进行 URL 处理，以保持 Nginx 配置的清晰和可预测性。如果只需要简单的外部重定向（返回 301/302），使用 return 指令通常更高效和安全。

nginx location /old-url { return 301 /new-url; # 推荐用于外部重定向 }

7. 避免在 Location 模式中使用查询字符串

location 指令是基于请求的 URI 进行匹配的，这个 URI 不包含 查询字符串（? 后面部分）。如果你需要根据查询字符串来进行路由，你可能需要使用 if 指令或者 map 指令结合 $arg_parameter 变量，但这通常会让配置变得复杂，且 if 指令在 Nginx 中有一些已知的“坑”，不建议过度使用。大多数情况下，基于路径的匹配已经足够。

第六部分：调试 Location 匹配问题

当你发现 Nginx 的请求路由不按预期工作时，很可能是 location 匹配规则理解有偏差或者配置错误。以下是一些调试技巧：

检查 Nginx 配置语法： 运行 nginx -t 命令检查配置文件是否存在语法错误。
查看 Nginx 错误日志： 错误日志（通常在 /var/log/nginx/error.log 或自定义路径）会记录 Nginx 启动、停止以及处理请求时遇到的错误，包括配置加载问题。
查看 Nginx 访问日志： 访问日志（通常在 /var/log/nginx/access.log 或自定义路径）记录了每个请求以及 Nginx 如何处理它，包括响应状态码。虽然默认访问日志不直接显示匹配了哪个 location，但你可以通过自定义日志格式来输出相关信息，例如 $uri 变量可以显示请求的 URI。
手动跟踪匹配过程： 对于一个特定的 URI，根据本文介绍的优先级规则，一步一步地在你的 Nginx 配置文件中查找应该匹配哪个 location。这是最有效的方法。
精简配置进行测试： 暂时注释掉大部分 location 块，只保留可能相关的几个，逐步放开并测试，找出问题所在。
在线 Nginx 配置解析工具： 有一些在线工具可以帮助你分析 Nginx 配置文件的 location 匹配规则，输入配置和 URI，它会告诉你哪个 location 会被匹配。但要注意这些工具可能无法完全模拟所有 Nginx 版本和模块的行为。
使用 Nginx 调试日志： 如果编译 Nginx 时开启了调试模块，可以开启调试日志（error_log /path/to/debug.log debug;），它会输出非常详细的匹配过程信息，但这会产生巨大的日志量，只应在调试时临时开启。

通过系统地检查配置、理解规则并结合日志分析，通常可以定位 location 匹配问题。

第七部分：总结

location 指令是 Nginx 配置的基石，掌握它的匹配规则对于高效、安全、稳定地运行 Nginx 至关重要。

核心要点：

location 块 根据请求 URI 定义不同的处理逻辑。
不同的修饰符 (=, ^~, ~, ~*, 无) 定义不同的匹配方式（精确、优先前缀、正则表达式、普通前缀）。
匹配优先级 遵循一个明确的顺序：= (精确) > ^~ (优先前缀) > ~/~* (正则表达式 – 按顺序第一个) > 无修饰符 (最长前缀) > / (根路径)。
正则表达式 的匹配顺序取决于它们在配置文件中出现的顺序。
location 块内部包含处理请求的各种指令，如 root, alias, index, try_files, proxy_pass 等。
^~ 对于优化静态文件服务非常有用，能跳过后续的正则表达式检查。
rewrite 指令会影响 location 匹配过程，使用时需谨慎。return 通常是更好的选择。
location / 是所有匹配失败后的默认处理块。
调试时，理解优先级规则并查看日志是最有效的方法。

从入门到精通 location 匹配规则需要时间和实践。多写配置，多测试，多调试，逐步建立起对 Nginx 如何处理请求的直观感觉。一旦掌握了 location 的精髓，你将能轻松应对各种复杂的 Nginx 配置需求。

希望本文能帮助你全面理解 Nginx 的 location 匹配规则！

Nginx location 匹配规则从入门到精通 – wiki基地

Nginx Location 匹配规则：从入门到精通

第一部分：初识 Location – 它是什么以及为什么重要？

第二部分：Location 匹配类型 – 看懂那些符号

1. 前缀匹配（Prefix Matching） – 无修饰符

2. 精确匹配（Exact Matching） – 修饰符 `=`

3. 正则表达式匹配（Regular Expression Matching） – 修饰符 `~` 和 `~*`

4. 优先前缀匹配（Preferential Prefix Matching） – 修饰符 `^~`

总结不同匹配类型的特点和用途：

第三部分：Location 匹配优先级 – Nginx 如何做选择？

第四部分：常用指令与 Location 块的组合

第五部分：高级话题与最佳实践

1. 根路径 `/` 的特殊性

2. 利用 `^~` 优化静态文件服务

3. 正则表达式的顺序很重要

错误的顺序示例

如果请求是 /specific/page.html，它会先匹配到第一个 location，第二个 location 永远不会被使用。

正确的顺序示例

4. 避免复杂的嵌套 Location

5. 使用命名 Location (`@`)

6. Location 和 Rewrite 的交互

7. 避免在 Location 模式中使用查询字符串

第六部分：调试 Location 匹配问题

第七部分：总结

发表评论取消回复

Nginx Location 匹配规则：从入门到精通

第一部分：初识 Location – 它是什么以及为什么重要？

第二部分：Location 匹配类型 – 看懂那些符号

1. 前缀匹配（Prefix Matching） – 无修饰符

2. 精确匹配（Exact Matching） – 修饰符 =

3. 正则表达式匹配（Regular Expression Matching） – 修饰符 ~ 和 ~*

4. 优先前缀匹配（Preferential Prefix Matching） – 修饰符 ^~

总结不同匹配类型的特点和用途：

第三部分：Location 匹配优先级 – Nginx 如何做选择？

第四部分：常用指令与 Location 块的组合

第五部分：高级话题与最佳实践

1. 根路径 / 的特殊性

2. 利用 ^~ 优化静态文件服务

3. 正则表达式的顺序很重要

错误的顺序示例

如果请求是 /specific/page.html，它会先匹配到第一个 location，第二个 location 永远不会被使用。

正确的顺序示例

4. 避免复杂的嵌套 Location

5. 使用命名 Location (@)

6. Location 和 Rewrite 的交互

7. 避免在 Location 模式中使用查询字符串

第六部分：调试 Location 匹配问题

第七部分：总结

发表评论 取消回复

2. 精确匹配（Exact Matching） – 修饰符 `=`

3. 正则表达式匹配（Regular Expression Matching） – 修饰符 `~` 和 `~*`

4. 优先前缀匹配（Preferential Prefix Matching） – 修饰符 `^~`

1. 根路径 `/` 的特殊性

2. 利用 `^~` 优化静态文件服务

5. 使用命名 Location (`@`)

发表评论取消回复