nginx location匹配按固定顺序逐条检查，命中即停：=精确匹配→^~前缀优先→~和~*正则（首匹配）→无修饰符最长前缀。query string不影响匹配。
理解 location 优先级不靠死记，而靠抓住 Nginx 的匹配逻辑：它不是“选最像的”，而是“按固定顺序逐条检查，一旦命中就停”。排查时关键在还原 Nginx 实际走哪一步，而不是猜它“应该”怎么走。
先搞清四类匹配的本质区别
每种修饰符解决不同问题，混用就会出错：
-
=（精确匹配）：只认完整路径，连末尾斜杠、查询参数都不参与比较（但问号后内容本身被忽略）。比如
location = /api只响应GET /api，/api/或/api?v=1都不中。 - ^~（前缀优先）：只要 URI 以该字符串开头就匹配，且立刻终止正则检查。适合静态资源目录，避免图片后缀规则干扰路径前缀判断。
- ~ 和 ~*：纯正则，区分或不区分大小写。它们不按“更长”或“更准”选，只按配置文件里出现的顺序——第一个匹配上的就生效，后面不管多贴切也跳过。
-
无修饰符（普通前缀）：最长前缀胜出，但仅在前面三类都没命中时才轮到它。注意：
location /a和location /ab同时存在，请求/abc会进/ab，不是因为写了“ab”，而是它更长。
排查 location 冲突的实用方法
别只看配置，要验证 Nginx 实际行为：
- 用
nginx -t检查语法正确，但不保证逻辑合理；真正要看的是运行时匹配路径。 - 在每个 location 块里加
add_header X-Location-Match "xxx";，用curl -I查看响应头，直接看到哪个块被触发。 - 对有疑问的请求，开启 Nginx 调试日志（
error_log /path/to/debug.log debug;），搜索"*xx location"关键字，日志会明确写出“using configuration”和“matched location”。 - 特别注意 query string（? 后面）——它完全不影响任何 location 匹配，只在 proxy_pass 或 rewrite 中可能被传递或操作。
常见陷阱与绕过思路
很多问题其实源于设计意图和匹配机制错位：
- 想让
/admin走后台，又让/admin/api走 API 服务？不能只靠前缀，得用location = /admin+location ^~ /admin/api+location /admin分层控制。 - 正则写太多导致难维护？把高频、确定的路径尽量用
=或^~提前拦截，留给正则处理动态或泛化规则（如~ \.js$）。 - 发现请求进了意料之外的 location？先确认是否被更高级别匹配截断——比如本想进
location ~ \.php$，但前面有个location ^~ /phpmyadmin，而请求是/phpmyadmin/index.php，那正则根本不会执行。
一个最小可验证配置示例
快速测试优先级，把这段放进 server 块：
location = /test { return 200 "exact\n"; }
location ^~ /test { return 200 "prefix-high\n"; }
location ~ /test { return 200 "regex\n"; }
location /test { return 200 "prefix-longest\n"; }
location / { return 200 "fallback\n"; }
然后测试：curl http://localhost/test → “exact”curl http://localhost/test/123 → “prefix-high”（^~ 拦住，正则不执行）curl http://localhost/atest → “regex”（正则匹配了 /test 字符串）curl http://localhost/testme → “prefix-longest”（/test 是最长前缀）
