Nginx路径匹配遵循严格优先级规则而非配置顺序：精确匹配（=）仅限无参固定路径；前缀匹配以最长路径为准，推荐统一加尾斜杠或用^~避免正则干扰；正则匹配优先级更高但需谨慎 placement；静态资源必须显式声明并区分root/alias。
Nginx 路径匹配出问题，往往不是配置写错了，而是没搞清它的匹配逻辑。它不按文件里写的顺序来，也不靠“谁在前面谁优先”，而是有一套严格的优先级规则。只要理解清楚这几点，90% 的路径路由异常都能快速定位和修复。
精确匹配（=）用错场景
很多人以为 = 是“最保险”的写法，其实它只适合真正需要“完全相等”的路径，比如 /favicon.ico、/healthz 这类无参数、无后缀的固定端点。如果写成 location = /api，那 /api/ 或 /api/users 都不会命中——它连末尾斜杠都不容许多一个。
- ✅ 正确用法：
location = /favicon.ico { ... }，只响应这个单一请求 - ❌ 错误用法：
location = /admin想匹配所有后台路径，结果所有带子路径的请求全失效 - ? 替代方案：想让
/admin及其所有子路径都走同一组配置，应去掉=，改用location /admin/ { ... }
前缀匹配被更长路径覆盖
常见陷阱是把通用规则写在了具体规则前面，比如：
location / { proxy_pass http://backend; }
location /api/ { proxy_pass http://api; }看似合理，但 Nginx 实际会先收集所有前缀匹配项，再选最长的那个——/api/ 比 / 更长，所以 /api/users 仍能正确匹配。但如果漏写了末尾斜杠，写成 location /api，那它反而比 /api/ 短，可能被 / 吞掉。
- ✅ 推荐写法：统一加尾部斜杠，如
/api/、/static/、/admin/ - ✅ 更稳妥写法：对关键路径使用
^~，例如location ^~ /api/ { ... }，可跳过正则阶段，确保前缀匹配胜出 - ⚠️ 注意：
^~不改变长度比较逻辑，只是禁止后续正则匹配参与竞争
正则与前缀混用导致意外交替
正则匹配（~ 或 ~*）优先级高于普通前缀匹配，但仅当它出现在匹配结果中时才生效。也就是说，Nginx 先找所有前缀匹配中最长的，再看有没有正则能匹配当前 URI——如果有，且该正则优先级更高（比如更早定义或更具体），就可能“抢走”请求。
- ✅ 安全做法：把正则规则放在配置末尾，避免干扰前缀路由主干
- ✅ 精准写法：限制正则范围，如
location ~* \.(js|css|png|jpg)$，别用太宽泛的location ~ .* - ? 小技巧：用
location ^~ /static/+location ~* \.js$组合，既保证静态目录走前缀，又允许对特定后缀做额外处理
静态资源路径被主服务兜底
典型现象：访问 /static/main.css 却返回了后端服务的 HTML 页面或 404。这是因为 location / 这个兜底规则太“贪心”，而 /static/ 规则要么没写、要么写得不够明确、要么顺序不对。
- ✅ 必须显式声明静态路径，例如：
location /static/ { alias /var/www/assets/; } - ✅ 注意
root和alias的区别：前者拼接完整路径，后者直接替换匹配部分 - ✅ 加上缓存头：
expires 1y;和add_header Cache-Control "public";提升性能
