Nginx的location匹配按四类优先级执行：先精确匹配（=），再最长前缀匹配（无修饰符或^~），接着按配置顺序尝试正则匹配（~或~*），最后兜底通用前缀匹配。
Nginx 的 location 匹配不是按配置文件书写顺序执行的，而是严格遵循匹配优先级规则。所谓“顺序颠倒”，其实是误解了 Nginx 的匹配逻辑——它不会从上到下逐条比对，而是先分类、再按优先级选最优匹配项。
理解 location 匹配的四类优先级
Nginx 将所有 location 块分为四类，按以下固定顺序判断（一旦某类中找到完全匹配，就不再继续）：
-
精确匹配（
=）：如location = /api，必须完全一致，优先级最高 -
最长前缀匹配（无修饰符或
^~）：如location /static/或location ^~ /img/，取 URI 最长的前缀匹配项 -
正则匹配（
~或~*）：按配置文件中出现的自上而下顺序尝试，遇到第一个成功匹配即停止（区分大小写 / 不区分） - 通用前缀匹配（无修饰符，且未被前面三类命中）：兜底项，取最长前缀
用 nginx -T 和 curl 验证实际匹配路径
光看配置容易误判，需结合工具确认真实行为：
- 运行
nginx -T（注意大写 T）输出完整展开配置，检查location块是否被 include 混淆、是否在 server 块内嵌套错误 - 用
curl -I http://host/xxx加-v查看响应头中的Server或自定义add_header X-Matched-Location "xxx"辅助定位 - 在关键 location 中临时加
return 499 "matched: /foo";，直观看到哪个块生效
常见导致“看似颠倒”的典型写法
这些写法会让预期和实际不一致，但其实都符合规则：
-
location /api/ { ... }和location ~ ^/api/\d+$ { ... }：前者是前缀匹配，后者是正则；即使正则写在下面，只要 URI 是/api/123，仍会优先进入正则块（因前缀匹配只到/api/，而正则更精确） -
location / { ... }写在最上面，却没生效：因为有location = /或location ^~ /static/等更高优先级项存在 - 使用
^~却仍进入正则块：说明该路径未命中任何^~或=，才轮到正则；检查 URI 是否真以指定前缀开头（注意末尾斜杠、编码字符等）
调试时的关键检查点
遇到匹配不符合预期，按此顺序快速定位：
- 确认请求 URI 是否经过 rewrite、proxy_pass 或内部重定向（如
try_files），原始请求可能已被改写 - 检查是否在多个 server 块或通过 include 引入了隐藏的 location（
nginx -T | grep "location "全局搜索） - 验证正则表达式是否真正匹配：Nginx 正则基于 PCRE，
^和$锚定的是整个请求 URI（不含 query string），且不自动忽略末尾斜杠 - 避免混用
alias和root导致路径拼接异常，间接影响 location 选择逻辑
