Nginx 中路径匹配在虚拟主机配置中应用

Nginx location匹配优先级为：①精确匹配（=）→②前缀匹配（^~）→③区分大小写正则（~）→④不区分大小写正则（~*）→⑤普通前缀匹配→⑥通用匹配（/），匹配成功即停止后续搜索。

路径匹配是 Nginx 虚拟主机配置中控制请求分发的核心机制，它发生在 server 块内部，决定“同一个域名下的不同 URL 应由哪段逻辑处理”。没有 location 规则，虚拟主机就只能把所有请求交给同一套逻辑——这显然无法支撑真实网站的动静分离、API 路由、静态资源优化等需求。

location 是虚拟主机的“路由中枢”

每个 server 块代表一个虚拟主机（比如 example.com），而 location 块就是这个主机内部的子路由。Nginx 先根据 Host 头、IP 或端口选中某个 server，再用请求的 URI（如 /api/v1/user 或 /static/logo.png）去匹配该 server 内定义的 location 规则。

• 一个 server 可以包含多个 location，彼此互不干扰，各自承担不同路径职责
• location 不会跨 server 生效——它只在当前虚拟主机上下文中起作用
• server_name 和 listen 决定“谁来接这个请求”，location 决定“接到了之后怎么分发”

四类匹配方式的实际分工

不同修饰符对应不同场景，合理搭配才能避免冲突或遗漏：

• =：用于高频、固定路径，如 location = /favicon.ico 或 location = /robots.txt，跳过后续匹配，响应最快
• ^~：适合静态资源前缀，如 location ^~ /static/，匹配 /static/css/app.css 时立即终止正则搜索，防止被低优先级的 ~ .css$ 干扰
• ~*：常用在文件类型处理，如 location ~* .(js|css|woff2)$，不区分大小写，统一设置缓存头
• 无修饰符（普通前缀）：兜底或通用路径，如 location /admin 匹配所有以 /admin 开头的请求，但优先级低于 ^~ 和正则

匹配顺序直接影响行为结果

Nginx 不按书写顺序，而是严格按优先级执行匹配：

• 先找 = 精确匹配，命中即停
• 再找最长前缀匹配（含 ^~），若遇到 ^~ 则不再检查后面的正则
• 最后才按配置顺序扫描正则 ~ 和 ~*，第一个匹配即生效
• 所有都没中？默认落到 location /（只要存在）

例如：location ^~ /api/ 和 location ~ /api/vd+/user 共存时，请求 /api/v2/user 会进入前者而非后者——因为 ^~ 阻断了正则匹配流程。

常见组合实践示例

一个典型的生产型虚拟主机常这样组织 location：

• location = / → 返回首页或重定向
• location ^~ /assets/ → 指向磁盘静态目录，加 expires 1y
• location ~* .(png|svg|ico)$ → 单独控制图标类资源缓存策略
• location /api/ → 用 proxy_pass 转发到后端服务
• location / → 最后兜底，配合 try_files $uri $uri/ /index.html 支持单页应用（SPA）