Nginx location匹配按四步固定顺序执行：第一步=精确匹配即停；第二步^~最长前缀匹配后跳过正则；第三步按序执行首个匹配的~或~*正则；第四步无修饰符前缀中选最长，等长取先定义者。

Nginx 的 `location` 匹配不是“计算”出来的，而是按**固定顺序逐轮筛选、一旦命中即终止**的查找过程。它不依赖权重或公式，关键在于理解这四步不可跳过的匹配流程：

第一步：精确匹配（=）优先级最高

只看 URI 是否**完全一致**（忽略查询参数 ?xxx），匹配成功立刻结束搜索。

• 示例：location = /api 只响应 /api，不响应 /api/、/api?v=1 或 /apix
• 哪怕后面有更长的前缀规则，只要 = 匹配上了，就不用再往下看了

第二步：前缀匹配中带 ^~ 的优先处理

所有以 ^~ 开头的 location，会先参与“最长前缀”比对；一旦某个 ^~ 规则匹配上，Nginx 就跳过所有正则匹配，直接执行该块。

Nginx Config Linter

对 Nginx 配置文件进行语法检查、验证和安全、性能审计。

下载

• 示例：location ^~ /static/ 匹配 /static/css/app.css，即使配置里还有 location ~ \.css$，也不会触发
• 这个设计是为了性能和确定性——静态资源走这里，绝不被正则干扰

第三步：正则匹配按配置顺序逐条检查

只有前两步都没命中时，Nginx 才开始从上到下扫描所有 ~ 和 ~* 规则，遇到第一个匹配的就停，不再继续。

• 注意顺序：把更具体的正则写在前面，比如 ~ ^/api/v2/ 应该放在 ~ ^/api/ 上面，否则后者会提前截断
• ~* 不区分大小写，适合处理图片后缀等；~ 区分大小写，适合需严格控制的路径（如大小写敏感的 API 版本）

第四步：普通前缀匹配兜底选最长

如果前三步全没命中，Nginx 回头看所有无修饰符的 location /xxx，从中挑出URI 前缀最长的那个（不是最先定义的）。

• 示例：请求 /blog/post/2025，同时存在 location /blog 和 location /blog/post，会选择后者
• 若多个长度相同（比如 /a 和 /b 都匹配 /），取配置文件中先出现的那个

不复杂但容易忽略