nginx 无访问权限继承，权限控制依赖 location 匹配优先级、指令作用域及显式配置；auth_request 实现鉴权逻辑解耦，limit_req 和 allow/deny 等须在各 location 中单独配置。
Nginx 中没有真正意义上的“访问权限继承”，所有权限控制都依赖于 location 匹配优先级 + 指令作用域规则 + 显式配置覆盖，而不是父级自动传给子级。理解这点，就能避开绝大多数权限失效的坑。
location 匹配决定权限是否生效
一个请求只会进入一个 location 块（按最长前缀或首个匹配正则），该块内定义的权限指令（如 allow/deny、auth_request、limit_req）才起作用。
-
/admin/和/admin/settings/是两个独立匹配项，即使路径有包含关系，也不会自动共享权限配置； - 如果
/admin/settings/被更具体的location ^~ /admin/settings/捕获，而该块没写auth_request，那它就完全不鉴权； - 正则 location（如
location ~ \.php$）和前缀 location 互不影响，各自独立生效。
auth_request 是实现逻辑分层的关键
用内部 location 委托鉴权，可复用策略，避免重复写权限逻辑：
- 定义统一鉴权入口：
location = /auth/api { internal; proxy_pass http://auth/check?scope=api; } location = /auth/admin { internal; proxy_pass http://auth/check?scope=admin; } - 在不同 location 中调用对应端点：
location /api/ { auth_request /auth/api; proxy_pass http://backend; } location /admin/ { auth_request /auth/admin; proxy_pass http://admin-svc; }这样，权限判断解耦，修改策略只需改后端服务，Nginx 配置保持简洁。
limit_req 和 access 控制不继承，必须显式写
-
limit_req zone=xxx不会从/api/自动带到/api/v2/，哪怕后者被前者前缀覆盖； -
allow/deny同样只在当前 location 生效，且遵循顺序匹配（先写的allow或deny可能被后写的覆盖）； - 常见错误：只在
location /static/配了limit_rate，却忘了location ~ \.(js|css)$里没加，结果静态资源限速失效。
add_header 和安全头需逐 location 补全
-
add_header X-Frame-Options DENY;在 server 块设置后，若某个 location 也写了add_header，同名头会被清空重写； - 若希望所有响应都带某头（包括 403、500），必须加
always参数：add_header X-Content-Type-Options nosniff always;
- 不要指望子 location “自动带上”父级的安全头，每个需要响应头的 location 都得自己声明。
权限控制不是靠继承，而是靠精准匹配 + 显式委托 + 分散配置。把权限逻辑收口到 auth_request 后端，再配合清晰的 location 划分，比堆砌 if 和嵌套幻想可靠得多。
