nginx 前缀在匹配结束前只是候选配置
nginx location 在已选中的 server 内为请求选择配置。对于这里验证的平面前缀与正则结构，精确匹配会结束搜索；否则 nginx 先记住最长匹配前缀，再可能选择第一个匹配的正则。如果没有适用正则胜出，就使用先前记住的前缀。这是一个完整选择过程，不是简单执行配置文件里最先遇到的块，也不是只比较路径看起来有多具体。 坏掉的样子 前缀是字符串前缀，不会自动要求完整路径段。location /api 也能匹配 /apix。如果真正需要的是端点 /api 和 /api/ 下的后代，应明确表达这两个边界。依赖未声明的路径段边界，可能让只是共享开头字母的路径，进入错误处理器、缓存策略或访问规则。配置应反映真实 URL 集合，而不是依靠读者自行补充含义。 最长普通前缀不一定是最终选择。匹配 .php 的正则，可以接管一个也匹配了更详细 API 前缀的请求。把前缀移到正则之前，不会改变基本优先规则。竞争正则之间的声明顺序有意义，普通前缀则主要比较匹配长度，而不是出现位置。因此，单纯整理文本顺序不一定修复实际路由问题。 ^~ 在该前缀成为相关层级的最长匹配前缀时，抑制正则搜索。它不是正则运算符，也不是对所有以某个较短标记前缀开头的路径提供无条件保护。嵌套 location 和内部跳转需要额外推理；下面故意使用平面 server 结构，让每次选择都能明确对应一个规则，不把复杂嵌套情况隐藏在简化结论里。 快速验证 先取得固定 nginx 镜像，再用宿主 Python 和 Docker 运行脚本。实测为 Linux arm64 上的 nginx 1.28.0、Docker 29.3.1。它构建临时配置镜像，用 nginx -t 验证，再通过只发布到宿主回环的端口发送真实 HTTP 请求，最后清理自己的容器、镜像标签和网络，不改动已有站点配置： ...