Nginx配置继承按块层级和指令类型分规则：main→events/http→server→location→nested location；值指令向下继承并可覆盖，动作指令不继承，屏蔽指令子块生效优先；location匹配优先于继承，用nginx -T验证实际配置。
Nginx 配置文件的嵌套与继承不是简单的“父给子、子照搬”，而是一套有规则、分类型的上下文作用域机制。理解它，关键在于看清“块层级”和“指令类型”两个维度。
配置块的嵌套结构是明确的层级树
Nginx 的配置块按作用域从大到小依次为：main（全局）→ events / http → server → location → nested location。每个 {} 块只能出现在合法的父块中，比如 server 只能写在 http 里，location 只能写在 server 或另一个 location 里。这种嵌套不可越级，也不可乱序。
-
http块里的配置对所有下属server生效，但可被server中同名指令覆盖 -
server块中的root、index等值类指令，会被其内部所有location继承，除非该location自己重新定义 - 同一层级的多个
server或多个location之间互不影响，没有继承关系
指令继承不是全盘复制，而是按类型区别对待
不同指令在嵌套时行为完全不同，不能一概而论：
- 值指令（如 root、client_max_body_size、keepalive_timeout）：默认向下继承，但子块一旦声明，就完全替换父块值，不叠加、不合并
-
动作指令（如 proxy_pass、rewrite、limit_req）：不继承。必须在要生效的块中显式写出，写在
http或server里对location无效 - 屏蔽指令（如 add_header、error_page）：子块只要出现同名指令，父块对应设置即刻失效，响应中只保留子块定义的内容
location 匹配优先级高于继承逻辑
请求进来后，Nginx 先做 location 匹配，匹配成功后才加载该 location 块内的全部配置。这意味着：
- 即使
server块里写了proxy_pass，只要没写在匹配到的location里，就不起作用 - 一个请求只会进入一个
location（最长前缀匹配或正则优先），不会“跨 location 继承” - 嵌套
location（如location /api { location /api/v2 { ... } }）也遵循匹配优先，内层不自动获得外层未声明的动作指令
验证继承是否生效最直接的方法
别靠猜，用工具看实际生效配置：
- 运行
nginx -T（大写 T）：输出完整展开后的配置，所有继承、覆盖结果一目了然 - 配合
curl -I检查响应头，验证add_header是否被屏蔽 - 访问一个故意触发 404 的路径，确认
error_page是哪个层级生效的
