在 nginx 配置中，嵌套 location 块的处理逻辑遵循“最长前缀匹配”优先于“正则匹配”，且内部 location 继承外部 location 的配置指令。当请求 uri 同时命中多个位置时，nginx 会先确定最精确的前缀匹配块，然后在该块的上下文中继续处理内部定义的规则。这种机制允许将特定路径的通用配置与针对子路径的特殊配置隔离开来，避免全局配置污染局部行为。
如何区分前缀匹配与正则匹配的优先级
Nginx 在处理 location 时，首先扫描所有前缀（非正则）匹配项，选择长度最长的那个作为候选。如果存在正则表达式匹配，则按配置文件中的书写顺序执行，一旦某个正则匹配成功，立即停止后续的正则匹配并进入该分支。这意味着即使一个前缀匹配非常精确，只要有一个靠前的正则表达式命中，前缀匹配就会被忽略。理解这一顺序是解决冲突的关键，因为正则表达式的优先级实际上高于普通前缀匹配。
server {
listen 80;
server_name example.com;
# 前缀匹配：/api
location /api {
proxy_pass http://backend_api;
# 继承自 server 或上级 location 的配置
}
# 正则匹配：精确匹配 /api/v1/status
location ~ ^/api/v1/status$ {
return 200 'OK';
# 此规则会拦截上述 /api 下的 /api/v1/status 请求
}
}
在上述配置中，访问 /api/v1/status 会返回 200 OK，而不是被代理到后端 API。这是因为正则表达式 ~ ^/api/v1/status$ 在列表中靠前且匹配成功，触发了短路机制。若将正则块移至 /api 之后，或者修改正则使其不匹配，请求才会落入 /api 块并由 proxy_pass 处理。这种顺序依赖性要求开发者在编写配置时必须严格审查正则块的排列位置。
嵌套 location 如何继承与覆盖父级配置
当在一个 location 块内部定义另一个 location 块时，内部块完全继承外部块的所有有效配置指令，除非内部块显式覆盖了这些指令。这种继承关系是递归的，意味着深层嵌套的子块会拥有所有祖先块的配置集合。然而，并非所有指令都支持继承，例如 proxy_pass 通常需要在最终生效的 location 中明确指定，否则可能因上下文缺失而报错或行为异常。此外，try_files 和 root 等指令在嵌套结构中需要特别注意作用域，确保它们指向正确的物理路径或逻辑映射。
server {
listen 80;
server_name example.com;
root /var/www/html;
# 外层 location：处理静态资源
location /static {
expires 30d;
add_header Cache-Control "public";
# 内层 location：处理特定类型的文件
location ~* \.(jpg|jpeg|png)$ {
# 继承 expires 和 Cache-Control
# 但可能需要调整 root 或尝试不同的文件路径
try_files $uri =404;
}
}
}
在这个例子中，访问 /static/image.png 时，Nginx 首先进入外层 /static 块，应用 expires 和 add_header 指令。随后，由于 URI 匹配内层的正则表达式 ~* \.(jpg|jpeg|png)$，控制权转移到内层块。内层块继承了外层的缓存策略，但使用了独立的 try_files 来定位文件。如果内层块未指定 root，它将沿用服务器级别的 root 设置。这种继承机制使得配置模块化成为可能，但也增加了调试复杂度，因为错误可能源于未被显式覆盖的父级指令。
当嵌套 location 中出现重复指令时以哪个为准
在嵌套 location 结构中，如果内部块和外部块定义了相同的可覆盖指令，内部块的值将覆盖外部块的值。这种覆盖是直接的，不存在合并或累加效应。例如，如果外层设置了 client_max_body_size 1m，而内层设置为 5m，则进入内层块的请求将使用 5m 的限制。对于不可覆盖的指令，如 listen 或 server_name，它们在 location 块中无效，必须定义在 server 或 http 级别。因此，处理重复指令的核心原则是：检查指令是否支持在 location 上下文中重新定义，若支持，则以内层为准；若不支持，则忽略内层的定义并继续使用外层或全局默认值。
