nginx对多个前缀location采用最长前缀匹配而非书写顺序，易因误读导致请求被意外规则处理；需用nginx -t查看生效配置、add_header验证命中路径、^~避免正则覆盖、-t -v或debug日志辅助排查。
遇到多个前缀 location 相互包含（比如 /api/ 和 /api/v1/）时，Nginx 不会按书写顺序执行，而是严格按“最长前缀匹配”选中一个——但这个逻辑容易被误读，导致请求被意料之外的规则处理。排查这类覆盖问题，关键不是看配置写了多少条，而是确认 Nginx 实际选中了哪一条。
用 nginx -T 检查最终生效的完整配置
运行 nginx -T（注意大写 T）可输出合并后、带行号的全部生效配置，包括 include 进来的文件。重点观察目标 server 块里所有 location 的原始位置和实际内容，确认有没有被重复定义、拼写差异（如多空格、大小写）、或意外继承的指令干扰。
- 尤其注意是否混用了
location /api和location /api/：前者会匹配/api、/api/、/apixxx；后者才真正限定以/api/开头 - 检查是否有未注释掉的兜底规则（如
location / { ... }）在末尾悄悄接管了请求
用 curl + 自定义响应头快速验证命中路径
在每个疑似冲突的 location 块里临时加入唯一标识的响应头，例如：
location /api/ {
add_header X-Location-Hit "api-root";
proxy_pass http://gateway;
}
location /api/v1/ {
add_header X-Location-Hit "api-v1";
proxy_pass http://backend;
}
然后用 curl -I http://host/api/v1/users 查看返回的 X-Location-Hit 值，直接确认实际走的是哪条规则。这种方式比翻日志更快，也避免 rewrite 或内部重定向干扰判断。
注意普通前缀匹配与正则共存时的“二次覆盖”陷阱
即使你只写了前缀规则，只要配置里存在任何 ~ 或 ~* 正则 location，Nginx 就会在找到最长前缀后，继续扫描正则——若某条正则也匹配成功，它会**覆盖**前面的前缀结果。
- 例如：
location /Api/ { ... }和location ~ /servlet/ { ... }同时存在时，请求/Api/servlet/json会先匹配到/Api/（最长前缀），但随后被~ /servlet/捕获并覆盖 - 解决办法：把必须优先的前缀规则改用
^~，例如location ^~ /Api/ { ... }，这样匹配后直接终止，不再检查正则
用 nginx -t -v 开启详细语法校验（可选）
某些版本支持 nginx -t -v 显示更详细的解析过程（非所有发行版默认开启）。若环境允许，可配合调试日志（error_log /path/to/log debug;）启用 http 级别 debug 日志，搜索 “location match” 关键字，能看到每一步匹配决策，包括候选列表和最终选择依据。
