nginx配置继承按指令类型严格区分：值类指令（如root、access_log）子块定义即覆盖；动作类指令（如proxy_pass、limit_req）不继承，须显式声明；屏蔽型指令（如add_header、error_page）子块一写则父级同名配置彻底失效。
Nginx 的配置继承不是“父级传给子级”的简单复制，而是按指令类型严格区分行为：有的可被子块覆盖，有的必须显式重写，有的写了就直接切断上级配置。搞不清这点，就容易出现 location 里突然没日志、响应头全丢、静态资源 403、限流不生效等问题。
值类指令：有定义就覆盖，不叠加不拼接
这类指令设定具体数值或路径，比如 root、access_log、client_max_body_size。它们在上级未定义时，下级自动沿用；但只要子块写了同名指令，就完全替换，不保留、不合并。
- server 块设了
root /var/www/html，location/api里又写root /opt/backend，那该 location 所有请求都以/opt/backend为根，且 URI 前缀（如/api）仍会拼在后面 → 实际路径是/opt/backend/api/xxx - 想让
/static/直接映射到/data/assets/而不带前缀？不能用root，得改用alias /data/assets/ - http 块设了
client_max_body_size 20M，某个 server 改成10M，它下面所有未再覆盖的 location 就默认用 10M
动作类指令：不继承，必须本层显式写
代表实际行为的指令，比如 proxy_pass、limit_req、try_files，Nginx 不允许隐含执行。上级写了，对下级完全无效；要用就得在目标 location 或 server 里自己写。
-
proxy_pass只能在 location 块中使用，写在 http 或 server 块会报错，也不会向下传递 - server 块配了
limit_req zone=api burst=5，对所有 location 都不生效；每个要限流的 location 必须单独加这一行 - SPA 应用常用
try_files $uri $uri/ /index.html，这个只在当前 location 生效；上级 server 的 try_files 不会被继承
屏蔽型指令：一写就断链，上级同名配置彻底失效
典型如 add_header 和 error_page。它们不是“覆盖值”，而是“切断继承”——子块只要出现任意一条，同名的上级配置就全部不可见。
- server 块写了
add_header X-Frame-Options DENY，location 里哪怕只加一行add_header X-Backend nginx，响应头里就只剩这一行，DENY 消失了 - location 中定义
error_page 404 /404.html，不仅管本 location，还会屏蔽 server 级的 404 处理逻辑，即使请求没匹配到这个 location，也不会回退查找 - 同样道理，
proxy_set_header一旦在 location 中出现任意一条，就会中断从 server 继承，并触发 Nginx 默认的Host $proxy_host和Connection close覆盖 —— 这就是为什么加个Connection $switch会导致 Host 头被意外改掉
作用域与匹配优先级决定最终生效配置
Nginx 先按最长前缀或正则匹配选中一个 location，然后只看这个 location 块内有没有相关指令；没有才逐级向上找（server → http），但前提是“未定义”，不是“未匹配”。嵌套 location 之间也互不影响，不存在跨块叠加。
- 多个 location 块不会合并配置，Nginx 只走一个，选中后立即应用其内部定义
- location
/api/v1和/api是两个独立作用域，彼此 root、proxy_pass、add_header 互不干扰 - 如果某个 location 没写
root，也不在更外层定义过，则可能 fallback 到编译时默认路径，导致 404 或权限错误
