2.4 location匹配顺序与翻车现场

2.4 location匹配顺序与翻车现场

本节摘要：location 匹配不是"谁写前面谁生效"，而是精确、前缀 ^~、正则、普通前缀的固定优先级竞赛。本节用一次静态资源被错误代理的事故，把匹配规则一次讲透。

事故：图片请求打进了应用服务器

某天应用服务器 CPU 飙高，日志里大量 /static/avatar.png 请求。Nginx 配置里有两条 location：

location /static/ {
    root /data/www;
}
location ~* \.(png|jpg)$ {
    proxy_pass http://app_backend;   # 历史遗留：曾想统一图片处理
}
​

直觉上 /static/ 前缀更"具体"，但实际生效的是正则那条——所有 png 都被代理给了应用。正则优先级高于普通前缀，这就是事故根源。

完整匹配顺序

Nginx 决定用哪个 location 的流程是固定的五步：

四种修饰符的能力差异：

修复配置

理解顺序后，修复只需一个字符——普通前缀换成 ^~：

location ^~ /static/ {          # 前缀命中后不再查正则
    root /data/www;
    expires 7d;
}
location ~* \.(png|jpg)$ {
    proxy_pass http://app_backend;
}
​

再补一个高频技巧：= 用于已知热点路径，跳过整场匹配竞赛：

location = /healthz {           # 健康检查，精确命中即返回
    return 200 "ok";
    access_log off;
}
​

⚠️ 前缀匹配用的是 URI 的开头逐字符比较，/static 和 /static/ 不是一回事：前者会命中 /staticABC 这类意外路径，目录语义永远带斜杠。

rewrite 与 location 的配合

改写发生在 location 选择之前：rewrite 改变 URI 后会重新走一遍匹配（flag 为 last 时），这也是"改了 rewrite 后 location 行为全变"的原因。第二章只需要记住因果链：

请求 URI → rewrite 改写 → 重新匹配 location → 命中的 location 再处理
​

排错时先确认"进来的 URI 是什么"，再推"改写后是什么"，最后推"命中谁"。跳过中间步骤是绝大多数误判的来源。

用实测代替记忆

匹配顺序背十遍不如动手验证一遍。用 return 指令把每条 location 的命中情况直接变成响应体：

server {
    listen 8090;
    location /static/    { return 200 "prefix-normal\n"; }
    location ^~ /static/ { return 200 "prefix-caret\n"; }
    location ~* \.png$   { return 200 "regex-png\n"; }
    location = /static/a.png { return 200 "exact\n"; }
}
​

逐条 curl 观察结果，覆盖每个分支：

curl http://127.0.0.1:8090/static/a.png    # exact —— 精确匹配碾压一切
curl http://127.0.0.1:8090/static/b.png    # prefix-caret —— ^~ 拦住正则
curl http://127.0.0.1:8090/other/a.png     # regex-png —— 正则抢走普通前缀退路
​

这个实验环境值得长期留着：任何对匹配顺序的疑问，改两行配置 curl 一下就有答案，比争论和回忆可靠得多。

正则 location 的性能账

正则按书写顺序逐个尝试，URI 都要先过一遍正则引擎。十几条正则、每秒数万请求时，这个成本开始可见。优化手法有三层：能用前缀表达的不用正则（静态目录用 ^~）；热点路径用 = 精确匹配直接短路；正则族本身按命中率从高到低排序，最常命中的写在最前面。定位正则开销没有直接的计数器，间接方法是对比——把正则组整体注释掉换成一条前缀转发，压测对比 CPU，差值就是正则引擎的账。多数站点这笔账小到不用管，但每秒十万级请求的入口值得算一次。

还有一个工程实践层面的建议：location 的声明顺序应当反映设计意图。把 = 精确匹配的运维端点放最前，^~ 的静态目录次之，正则族再次，兜底的 / 放最后——阅读者顺着文件往下走，正好是从最特殊到最一般的优先级降序，与匹配规则的心理模型一致。翻车现场里的那条正则之所以能"偷走"静态流量，部分原因也是它孤零零躺在文件末尾，review 时没人意识到它还在场上。配置可读性不是审美问题，是事故预防的一部分。

再补一个容易误判的现象作为本节的实战收尾：配置里明明写了处理 /api/ 的 location，请求却进了兜底的 /。排查发现 URI 实际是 /api（无尾斜杠）且匹配的是精确的 /api 前缀规则，与 /api/ 并不相同——一字之差在 location 世界里是两个不同的前缀。规范的做法是对"目录型"路径同时收编两种写法：一条 rewrite 把无斜杠请求 301 到带斜杠形式，既统一了语义也让缓存键不分裂。这类"差一个字符"的坑，靠的还是那套实验环境加 curl 的验证习惯。

本节要点回顾

• 正则优先于普通前缀，静态目录要用 ^~ 保护；
• 五步匹配顺序：精确 → 最长前缀 → ^~ 拦截 → 正则顺寻 → 回退前缀；
• = 给热点路径，健康检查是最典型场景；
• rewrite 改 URI 后重新匹配，排错先还原改写链。