同一个 server 里，先写了 location /，后面才写 location /api/：

server {
    listen 127.0.0.1:8080;

    location / {
        return 200 "root\n";
    }

    location /api/ {
        return 200 "api\n";
    }
}

访问 /api/users，返回的是 api。把这两段的位置交换，结果也不变。

所以，不能把所有 location 都理解成“从上往下，遇到第一个匹配就结束”。

下面只讨论同一个 server 内、同一层级的常见 location，不涉及嵌套配置、rewrite 和内部重定向。

普通前缀先比较匹配长度

对于请求路径 /api/users，上面的两个前缀都能匹配：

/       匹配
/api/   也匹配，而且更长

Nginx 会记住匹配到的最长普通前缀。这里是 /api/，不是文件里写在前面的 /。

只有这两段配置时，请求最终进入 /api/。前缀配置的位置改变，不会改变哪一个前缀更长。

可以在测试配置的 http 块里使用上面的 server，然后请求：

curl http://127.0.0.1:8080/api/users

不过，“记住最长前缀”还不一定等于“最终就使用它”。配置里如果还有正则匹配，查找可能继续进行。

多个正则匹配，书写顺序就有影响

在同一个 server 中，再加一段：

location ~ \.json$ {
    return 200 "json-regex\n";
}

这时请求 /api/users.json，虽然匹配了 /api/ 前缀，也会匹配以 .json 结尾的正则。

Nginx 先记住最长前缀，再检查正则。正则命中后，可以使用正则对应的配置，因此这里返回 json-regex。

如果存在两个都能命中的正则，顺序更重要：

location ~ ^/api/ {
    return 200 "api-regex\n";
}

location ~ \.json$ {
    return 200 "json-regex\n";
}

对于 /api/users.json，两段正则都成立。Nginx 按它们在配置中的出现顺序检查，遇到第一个匹配就使用它，因此返回 api-regex。

把这两段交换，请求会返回 json-regex。

这也是为什么调整配置顺序，有时能改变结果，有时又完全没有作用：普通前缀与正则采用的选择规则不同。相关过程见Nginx 的请求处理说明。

匹配看的是 URI 路径，不包含查询参数。/api/users?format=.json 的路径是 /api/users，不会因为参数里出现 .json，就命中上面的结尾正则。

精确匹配和 ^~ 会改变查找过程

如果只想让一个确定的路径使用某段配置，可以使用 =：

location = /api/users.json {
    return 200 "exact\n";
}

精确匹配命中后，查找结束。/api/users.json 会进入这一段，不再继续比较其他普通前缀和正则。

但 /api/users.json/extra 是另一个路径，不属于这个精确匹配。

另一个常见写法是 ^~。先移除上面的精确匹配，再把原来的普通前缀配置替换为：

location ^~ /api/ {
    return 200 "api\n";
}

当它是匹配到的最长前缀时，Nginx 会使用这一段，并跳过同层级的正则检查。/api/users.json 因而返回 api。

这里有两个容易看错的地方。

^~ 修饰的是前缀匹配，本身不是正则。它也需要先成为最长匹配前缀；并不是某段只要加了 ^~，就能无条件压过更长的前缀。

也不要为了让配置“优先执行”，把所有前缀都改成 ^~。这样可能使原本需要命中的正则处理不再执行。规则与边界见Nginx 官方 location 文档。

排查请求命中了哪一段时，先取出实际 URI 路径，再确认配置使用的是普通前缀、正则还是精确匹配。普通前缀比较长度，重叠正则比较出现顺序，= 和 ^~ 则会改变后续查找过程。

配置写在前面是否有用，要看它属于哪一种匹配。

原来如此。

阅读原文：原文链接