nginx location匹配优先级为：先找最长前缀，=和^~立即终止匹配；普通前缀则继续按序匹配正则，首个成功即生效，否则回退该前缀。
Nginx 中，前缀 location 优先匹配，正则 location 后续匹配，但不是“先执行前缀、再执行正则”，而是：Nginx 先找**最长的前缀匹配**（不带 ^~ 或 = 的普通前缀），如果该前缀不带 ^~，且没有精确匹配（=），就会继续检查是否有正则 location 能匹配请求 URI；一旦找到第一个匹配的正则 location，就立即使用它，不再考虑其他前缀或正则。
location 匹配的完整流程（关键顺序）
理解这个流程，才能准确测试先后关系：
- 第一步：Nginx 收到请求后，先忽略正则，只比对所有 前缀 location（包括
=、^~和普通前缀），找出最长的前缀匹配项 - 第二步：如果这个最长前缀是
=（精确匹配），直接采用，结束匹配 - 第三步：如果是
^~（最高优先级前缀），也直接采用，跳过所有正则匹配 - 第四步：如果是普通前缀（例如
location /api/），则暂存该结果，继续扫描所有location ~ ...和location ~* ...正则规则，按它们在配置文件中出现的从上到下顺序逐个尝试匹配 - 第五步：一旦遇到第一个能匹配 URI 的正则 location，立即选用它，并停止后续所有匹配（包括后面定义的更长前缀或其它正则）
- 第六步：如果没有任何正则匹配，则回退使用第二步中暂存的那个最长普通前缀 location
用简单配置实测验证顺序
在 nginx.conf 或 server 块中添加如下 location 块（注意顺序）：
location /test/ {
return 200 "prefix: /test/\n";
}
location ^~ /test/ {
return 200 "prefix ^~: /test/\n";
}
location ~ ^/test/\d+\.html$ {
return 200 "regex: number html\n";
}
location ~* ^/test/.*\.png$ {
return 200 "regex case-insensitive: png\n";
}
location = /test/123.html {
return 200 "exact: /test/123.html\n";
}
然后用 curl 测试不同路径：
-
curl http://localhost/test/123.html→ 返回 "exact: /test/123.html"（=精确匹配优先） -
curl http://localhost/test/456.html→ 返回 "regex: number html"（普通前缀 /test/ 匹配后，正则从上到下第一个成功） -
curl http://localhost/test/abc.png→ 返回 "regex case-insensitive: png"（前面正则不匹配，轮到第二个） -
curl http://localhost/test/→ 返回 "prefix ^~: /test/"（^~阻断正则，即使下面有更长前缀或正则也不看） - 删掉
^~行，再测/test/→ 返回 "prefix: /test/"（无正则匹配，回落到最长普通前缀）
调试技巧：开启 error_log 查看匹配过程
在 nginx 配置的 http 或 server 块中加入：
error_log /var/log/nginx/debug.log debug;
重启 Nginx 后，访问任意路径，查看日志中类似：
... testing location "/test/123.html" ...
... using configuration "/test/
" ...
... test location: "^/test/\d+\.html$" ... matched ...
日志会清晰显示每一步比对和最终选择的 location，是验证顺序最可靠的手段。
常见误区提醒
- 正则 location 不是“全局后于前缀”，而是仅在最长普通前缀未被
=或^~锁定时才参与竞争 -
~*和~本身无优先级高低，只看定义顺序；但~*是大小写不敏感，可能更容易意外匹配 - URI 在匹配前已被解码（如
%20→ 空格），正则应针对解码后的字符串写 -
location /a/b和location /a/b/是两个不同前缀，后者更长，会优先于前者（当请求是/a/b/c时）
