Nginx配置指令遵循明确作用域规则：proxy_pass、root、alias、try_files、limit_req等不继承，完全替换；index、error_page、add_header等屏蔽上级同名设置；sendfile、client_max_body_size等可隐式继承。

在 Nginx 中，nginx.conf 的配置指令**不是全部继承的，也不是全部覆盖的**——它遵循一套明确的作用域规则：有些指令可以被子块继承（即未显式定义时沿用父级值），有些则必须在每个作用域中重新声明，还有些一旦在某一层出现，就会完全屏蔽上层同名设置。理解哪些指令“不继承”、哪些“会覆盖”，是写出可靠配置的关键。

哪些指令默认不继承？

多数与连接处理、性能调优和模块行为相关的指令属于“无继承”类型，即它们在 http、server 或 location 块中重新定义时，**不会自动叠加或合并父级值，而是完全替换**。常见例子包括：

• proxy_pass：只在 location 中生效，server 或 http 块中写无效（语法错误）
• root 和 alias：每个 location 需独立指定；上级 server 的 root 不会自动传入子 location，除非该 location 没有自己定义
• try_files：仅当前 location 有效，不会从 server 继承；若未设，Nginx 不会回退查找
• limit_req / limit_conn：必须在具体 location 或 server 中启用，不跨层级传递

哪些指令看似“覆盖”，实为“屏蔽”？

某些指令在子作用域中出现，并非简单覆盖，而是**切断继承路径，使上级同名配置彻底失效**。典型代表是：

• index：若 server 块设了 index index.html，而某个 location 写了 index index.php，则该 location 下不再尝试 index.html —— 不是“追加”，而是“重置”
• error_page：子块中的 error_page 404 /404.html 会屏蔽 server 级的同类设置，即使没匹配到，也不会向上回溯
• add_header：子 location 中定义会清除所有父级 add_header，只保留本级的（Nginx 1.7.5+ 后可加 always 改变行为，但默认仍不继承）

哪些指令真正支持继承？

少数全局性、基础性的指令允许隐式继承，前提是子块未显式声明。这类指令通常控制协议行为或基本响应头：

• sendfile、tcp_nopush、tcp_nodelay：可在 http 块设为 on，server 和 location 不设时沿用
• client_max_body_size：http 级设为 10M，则所有未覆盖的 server 和 location 都受此限制
• keepalive_timeout：同样逐级向下继承，除非被子块显式改写

如何避免踩坑？

实际配置中，别依赖“默认继承”，尤其对业务关键指令：

• 在每个 location 显式写 root 或 alias，避免路径解析出错
• 用 include 抽取公共配置（如通用 header、日志格式），而非靠继承保证一致性
• 测试时用 nginx -T 查看最终展开的完整配置，确认某条指令是否真的生效在目标作用域
• 注意文档中标注的 Context 字段（如 http, server, location）——只有列出的上下文才允许使用该指令