Nginx配置采用Main→Server→Location三级嵌套作用域结构，指令生效取决于所在层级及继承类型：Normal指令（如root）低层覆盖高层，Array指令（如access_log）下层完全替换上层，Action指令（如proxy_pass）不继承，Context-only指令（如listen）仅限特定层级。
nginx 的配置不是扁平列表，而是有明确层级关系的树状结构。指令生效与否，取决于它写在哪一层、以及该指令本身的继承规则——核心就是 Main → Server → Location 这三级作用域的覆盖与传递逻辑。
三级作用域的实际嵌套结构
一个典型配置中，这三层是物理嵌套的：
-
Main（全局）：最外层，不带花括号，控制整个 nginx 进程行为（如
worker_processes、error_log） -
Server（虚拟主机）：在
http { }块内，每个server { }定义一个独立站点（监听端口、域名、根目录等） -
Location（路由匹配）：嵌套在
server { }内，按 URI 前缀或正则匹配请求，决定如何处理具体路径（如静态文件服务、反向代理）
这种嵌套不是装饰性的，而是解析引擎构建 ngx_conf_t.ctx 指针数组的依据：每进入一层 {，就往 ctx[level] 写入对应模块的配置结构体地址；退出时回退 level。指令执行时通过 cf->ctx[cf->level - 1] 精准定位当前作用域的配置内存。
指令继承的四类行为模式
并非所有指令都“向下覆盖”。nginx 将指令按语义分为四类，继承逻辑各不相同：
-
Normal 指令（如
root、index）：低层定义直接覆盖高层。例如server中设root /a，location /api中设root /b，则该 location 下所有请求都以/b为根目录 -
Array 指令（如
access_log、fastcgi_param）：同级多次声明会追加，跨级则低层完全替换高层。即server里写两条access_log，会生成两个日志；但location里再写一条，就只用这一条，server的失效 -
Action 指令（如
proxy_pass、rewrite）：不继承，只在当前块生效。它们是“动作型”指令，一旦命中就立即触发行为，上层同名指令无意义 -
Context-only 指令（如
listen、server_name）：仅允许出现在特定层级。比如listen只能在server块，写在location里会报错invalid directive
常见继承陷阱与验证方法
配置未按预期生效，大概率是继承逻辑被误判：
-
location 中的 root 不生效？ 检查是否用了
alias而非root—— 二者拼接逻辑不同：root是拼完整 URI 路径，alias是替换掉匹配前缀 -
server 级 access_log 消失了？ 看子 location 是否也写了
access_log。Array 类型指令一旦在下层出现，上层就被整体覆盖 -
rewrite 在 location 里不跳转？ 确认该 location 是否被更优先的正则匹配（
~或~*）捕获，且 rewrite 后是否加了last/redirect等标志 - 验证实际生效配置：运行
nginx -T（大写 T），它会输出合并后的最终配置树，能清晰看到每条指令落在哪一层、是否被覆盖
