Nginx访问控制不按规则顺序执行，而是依作用域层级和匹配优先级生效；location匹配分=、前缀最长、正则（首匹即停）、^~（阻正则）四类；allow/deny最终以最后匹配项为准；server块间无继承，需用default_server兜底；禁用if+deny，改用map或auth_request。
Nginx 本身不按“规则先后顺序”逐条执行访问控制，而是依据配置块的作用域层级 + 匹配逻辑优先级来决定哪条规则最终生效。所谓“优先级冲突”，往往源于 location、server、if、allow/deny 等指令嵌套或重叠时，预期行为与实际行为不一致。解决关键在于理解 Nginx 的匹配机制，并主动隔离、明确边界。
location 块的匹配顺序决定访问控制入口
请求先被分配到某个 location，之后该 location 内定义的访问控制（如 allow/deny、auth_basic、return）才起作用。而 location 匹配有严格优先级： - 精确匹配（=）：如 `location = /admin`，最高优先级，命中即停 - 前缀最长匹配（无修饰符或 ^~）：如 `location /api/` 和 `location /api/v2/`，后者更长，优先选后者 - 正则匹配（~ 或 ~*）：按配置文件中出现顺序，第一个匹配即生效，不再往后查 - `^~` 能阻止后续正则检查：`location ^~ /static/ { deny all; }` 会直接拒绝，不进入 `location ~ \.php$` 等正则块建议：高敏感路径（如 /admin, /backup.php）用 = 或 ^~ 显式锁定；避免用泛正则覆盖关键路径。
allow/deny 的执行是“最后胜出”，不是“最先匹配”
在同一个 location 中，`allow` 和 `deny` 指令按书写顺序逐条执行，但**最终生效的是最后一条匹配成功的指令**。例如：location / {
deny 192.168.1.100;
allow 192.168.1.0/24;
deny all;
}结果是：所有请求都被 deny all 拦截——因为它是最后一条生效的匹配项。
更安全写法是显式收口：
location / {
allow 192.168.1.0/24;
deny all; # 明确兜底，意图清晰
}注意：satisfy any 可绕过 IP 限制（如配合 auth），但需谨慎启用，否则可能削弱访问控制。
server 块间不存在“规则继承”，default_server 是兜底关键
多个 server 共享同一端口（如 `listen 80`）时，Nginx 根据 Host 头选择 server 块，**各块内访问控制完全独立，互不影响**。但若 Host 不匹配任何 `server_name`，就会落到 `default_server` ——此时若该块没配 deny 规则，可能意外放行。常见风险场景：
- 仅配置了
server_name example.com，但用户直接用 IP 访问 → 进入第一个 server 块（隐式 default） - 多个 server 都写了
server_name localhost→ Nginx 报 warning，只取第一个，其余被忽略
正确做法：
server {
listen 80 default_server;
server_name _; # 通配符兜底
return 444; # 直接关闭连接，不响应
}这样可杜绝未声明域名或 IP 直连导致的规则“失效”。
避免 if + 访问控制组合，改用 map 或 auth_request
`if` 在 location 中不可靠，尤其搭配 `allow/deny` 时行为难预测（Nginx 官方明确不推荐）。例如：# ❌ 危险写法：if 中的 deny 不一定生效
location / {
if ($arg_token = "") {
deny all;
}
}替代方案：
- 用
map提前标记变量，再在 location 中基于变量控制：map $arg_token $is_valid { "" 0; default 1; } location /api/ { if ($is_valid = 0) { return 403; } proxy_pass http://backend; } - 更健壮的做法是用
auth_request转交至内部鉴权服务，把复杂逻辑移出 Nginx 配置。
不复杂但容易忽略。
