Nginx 中如何通过 Nginx 配置继承访问权限

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 和嵌套幻想可靠得多。