梳理 nginx 多级继承关系的核心在于理解配置指令的作用域（context）以及 `include` 指令的静态展开机制。nginx 的配置并非通过面向对象的多态继承，而是基于文件包含和块嵌套的线性合并。当解析器遇到 `server`、`location` 或 `http` 块时，它会先加载该块内的显式配置，若未找到特定指令，则向上回溯查找父级作用域中的定义。这种“就近原则”决定了最终生效的配置值。要理清这种关系，需要关注 `nginx.conf` 主文件如何拆分业务配置，以及各个子配置文件之间的层级依赖。
主配置文件与模块引入结构是怎样的
主配置文件 `nginx.conf` 通常作为入口，定义了全局变量、用户权限、工作模式以及核心的 `http` 块。在 `http` 块内部，通常会通过 `include` 指令引入其他配置文件，如 `mime.types` 用于映射文件类型，以及 `conf.d/*.conf` 或 `sites-enabled/*` 用于存放具体的虚拟主机配置。这种结构将全局设置与站点配置分离，使得继承关系更加清晰：全局设置在 `http` 层定义，站点配置在 `server` 层覆盖或补充这些设置。
worker_processes auto;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
# 引入所有 conf.d 目录下的配置文件
include /etc/nginx/conf.d/*.conf;
}
上述代码展示了典型的 Nginx 主配置结构。`worker_processes` 和 `events` 块属于主上下文（main context），影响整个进程。`http` 块包含了 MIME 类型映射、默认类型、发送文件开关和保持连接超时时间。最后，`include /etc/nginx/conf.d/*.conf;` 这一行是关键，它告诉 Nginx 去读取指定目录下的所有 `.conf` 文件。这些被引入的文件将在当前 `http` 块的上下文中被解析，它们定义的 `server` 块将成为 `http` 块的直接子节点。
Server 块与 Location 块的继承逻辑是什么
在具体的站点配置中，`server` 块继承自 `http` 块，而 `location` 块继承自 `server` 块。这意味着如果在 `server` 块中没有明确指定某个指令，Nginx 会去 `http` 块中寻找该指令的值。同样，如果 `location` 块中没有指定，则会去 `server` 块中查找。这种继承是单向且严格的，子块可以覆盖父块的设置，但不能删除父块中已存在的非覆盖型设置（如某些列表类型的指令可能会追加而非替换，具体取决于指令特性）。例如，`proxy_pass` 通常在 `location` 中定义，但如果省略，可能会报错或使用默认行为，具体取决于上下文。
server {
listen 80;
server_name example.com;
root /var/www/html;
index index.html;
location / {
try_files $uri $uri/ =404;
}
location /api {
proxy_pass http://backend;
proxy_set_header Host $host;
}
}
这段代码展示了一个 `server` 块的典型结构。`listen` 和 `server_name` 定义了监听端口和域名。`root` 和 `index` 定义在 `server` 级别，意味着除非在特定的 `location` 中重新定义 `root`，否则所有请求都将使用 `/var/www/html` 作为根目录。第一个 `location /` 块处理所有根路径请求，使用 `try_files` 尝试返回文件或目录，失败则返回 404。第二个 `location /api` 块专门处理以 `/api` 开头的请求，它将请求代理到名为 `backend` 的上游服务器，并设置了 `Host` 头。注意，`proxy_set_header` 仅在 `location /api` 中生效，不会影响 `location /`。如果 `location /api` 中没有定义 `root`，它将继承 `server` 级别的 `/var/www/html`，但这对于代理请求通常没有实际意义，因为代理请求不直接读取文件系统。
当多个 Location 块匹配同一 URI 时如何处理
当请求的 URI 可能匹配多个 `location` 块时，Nginx 遵循特定的优先级规则来确定使用哪个块。首先，精确匹配（`= /path`）具有最高优先级。其次，前缀匹配（`/path`）中，最长前缀优先。例如，`/api/v1` 会匹配 `/api` 和 `/api/v1`，如果两者都存在，`/api/v1` 会被选中。再次，正则表达式匹配（`~` 或 `~*`）在普通前缀匹配之后进行，但如果有多个正则匹配，则按配置文件中的出现顺序执行第一个匹配的正则块。最后，如果没有任何前缀或正则匹配，则使用默认的前缀匹配（通常是 `/`）。这种机制确保了配置的确定性和可预测性，开发者可以通过调整 `location` 的顺序和类型来控制请求的路由。
server {
listen 80;
server_name example.com;
location = /exact {
return 200 "Exact match";
}
location /prefix {
return 200 "Prefix match";
}
location ~ ^/regex {
return 200 "Regex match";
}
}
以上代码演示了不同 `location` 类型的优先级。对于请求 `/exact`，Nginx 会命中 `location = /exact`，因为它是最精确的匹配。对于请求 `/prefix/test`，它会命中 `location /prefix`，因为它是与前缀最匹配的块。对于请求 `/regex/test`，它会命中 `location ~ ^/regex`，因为前缀匹配 `/prefix` 不匹配，而正则表达式匹配成功。需要注意的是，正则表达式匹配是在所有前缀匹配完成后才进行的，即使有一个更短的前缀匹配，只要没有更长的前缀匹配，正则表达式就有机会被触发。此外，如果存在多个正则表达式匹配，只有第一个出现的会被执行。这种复杂的匹配逻辑要求开发者在编写配置时仔细考虑 URI 的模式，以避免意外的路由行为。
