Nginx location匹配优先级为：=（精确）＞^~（前缀最长且阻正则）＞正则（按序首中）＞/（通用前缀），server选中依赖listen套接字与SNI匹配，location不嵌套但多块覆盖易引发隐性冲突，需结合debug日志与curl验证实际路径。
排查 Nginx 中 location 嵌套与匹配优先级冲突，关键不是看配置写了多少行，而是还原请求实际走哪条路径：先确认进对了 server，再验证命中了哪个 location，最后检查 rewrite 或访问控制是否在该块内生效。很多 404、跳转失效、代理被吞的问题，根源都在这两层路由没对上。
第一步：确认 server 块是否被正确选中
Nginx 不是“找第一个匹配的 server_name”，而是按三步筛选：
- 内核根据 TCP 目的 IP 和端口，把连接分发到对应 listen 套接字上；只有该 listen 下定义的 server 块才参与后续筛选
- 若多个 server 块监听同一端口（如 443），有 SNI 的请求按 server_name 精确或通配符匹配；无 SNI 的请求落到 default_server，没设就用第一个定义的 server 块
- 漏写 listen ssl 或 default_server 标识，尤其在多域名 HTTPS 场景下，会导致证书错配、跳转失败
第二步：验证 location 是否命中预期块
即使 server 对了，location 匹配错也会导致规则不执行。Nginx 严格按优先级选 location，不是按配置顺序：
-
=（精确匹配）：完全相等才生效，如
location = /health，最高优先级，命中即停 -
^~（前缀最长且阻正则）：如
location ^~ /static/，一旦匹配成功，直接终止，不再检查任何正则 location - ~ 或 ~*（正则匹配）：按配置文件中出现顺序逐条试，首个命中即停；但前提是前面 = 和 ^~ 都未匹配
- /（通用前缀）：仅当以上全不满足时才用，取最长前缀
典型陷阱：请求 /api/static/app.js 会进入 location ^~ /api/，哪怕后面还配了 location ~ \.js$；而 /admin/index.js 却可能被正则劫持——若该正则块里没配 root 或 proxy_pass，就直接 404。
第三步：检查嵌套逻辑是否引发隐性覆盖
location 块之间不继承，也不嵌套（语法上不允许嵌套 location）。所谓“嵌套冲突”，常指以下情况：
- 多个 location 覆盖同一路径段，例如同时存在
location /api/和location ^~ /api/v2/，后者因前缀更长且带 ^~，会屏蔽前者对/api/v2/xxx的处理逻辑 - 在 server 块中误用
if+deny：Nginx 不推荐在 location 外或内用 if 控制访问，容易绕过预期逻辑；应改用map预判变量，或auth_request委托鉴权 - rewrite 在 server 层执行后改变了 URI，导致后续 location 匹配结果变化；可用
add_header X-Debug-Uri $request_uri;或return 200 "$request_uri → $uri";快速验证 URI 是否被重写
第四步：用日志和测试快速定位
启用 debug 日志可直观看到匹配过程（需编译时含 --with-debug）：
- 加配置：
error_log /var/log/nginx/debug.log debug;，然后触发请求，查日志中类似"*1 using configuration \"= /health\""或"*1 using configuration \"^~ /static/\""的提示 - 用 curl 模拟不同请求路径，配合
curl -I查看响应头中的X-Debug-Uri或自定义标识，确认是否进入目标块 - 对高敏感路径（如
/admin、/backup.php），强制使用=或^~显式锁定，避免被泛正则意外覆盖
