Nginx路径匹配的配置指南

Nginx的location配置，你是“迷路小菜鸟”还是“火箭工程师”？

你有没有遇到过这些“坑”：

• /api的请求被分配到/static目录？
• /favicon.ico的请求总被忽略？
• 正则匹配和前缀匹配打架？

这就是 Nginx的location匹配规则 的“魔法”！它让你的请求处理像“高速公路”一样高效，像“瑞士军刀”一样灵活。

本文将带你从 “迷路小菜鸟” 到 “火箭工程师”，手把手教你写出“神级配置”！

第一战：基础操作——“快递分拣站”的规则

1.1 精确匹配（=）：快递员的“人脸识别”

问题：只有完全相同的路径才能触发配置？

解决方案：用 = 实现精确匹配！

# 精确匹配 /favicon.ico
location = /favicon.ico {
    root /var/www/static;  # 指定静态文件路径
    expires 30d;           # 浏览器缓存30天
}

# 请求示例：
# ✅ 匹配：http://example.com/favicon.ico
# ❌ 不匹配：http://example.com/favicon.ico?version=1

注释：

• = /path：必须完全匹配，连查询参数（?后的内容）都不行！
• root vs alias：
  • root：路径拼接（如 /favicon.ico → /var/www/static/favicon.ico）。
  • alias：路径替换（如 /static/images/logo.png → /var/www/images/logo.png）。

1.2 前缀匹配（无修饰符）：快递员的“地址模糊搜索”

问题：想匹配所有以 /api 开头的请求？

解决方案：用 普通前缀匹配！

# 匹配所有以 /api 开头的路径
location /api {
    proxy_pass http://backend_api;  # 反向代理到后端API
}

# 请求示例：
# ✅ 匹配：/api/user、/api/v1/login
# ❌ 不匹配：/apicheck（因为开头不是/api）

注释：

• 最长前缀优先：如果有两个前缀匹配（如 /api 和 /apic），Nginx会选最长的。
• 结尾斜杠的玄机：
  • location /api/：必须以 /api/ 开头（如 /api/123）。
  • location /api：会匹配 /api 和 /apic！

第二战：正则匹配——“快递员的魔法滤镜”

2.1 区分大小写的正则匹配（~）：快递员的“显微镜”

问题：想区分 .jpg 和 .JPG？

解决方案：用 ~ 实现区分大小写的正则匹配！

# 匹配以 .jpg 结尾的图片（区分大小写）
location ~ \.jpg$ {
    root /var/www/images;
    expires 30d;
}

# 请求示例：
# ✅ 匹配：/photo.jpg
# ❌ 不匹配：/photo.JPG

注释：

• 正则语法：\. 表示匹配点号，$ 表示结尾。
• 正则顺序敏感：多个正则匹配时，Nginx按配置顺序选择第一个匹配的！

2.2 不区分大小写的正则匹配（~*）：快递员的“全息扫描”

问题：想同时匹配 .jpg、.JPG、.png？

解决方案：用 ~* 实现不区分大小写的正则匹配！

# 匹配所有图片格式（不区分大小写）
location ~* \.(jpg|png|gif)$ {
    root /var/www/images;
    expires 30d;
}

# 请求示例：
# ✅ 匹配：/logo.PNG、/banner.gif

注释：

• 多格式匹配：用 | 分隔多个后缀（如 jpg|png|gif）。
• 性能注意：不区分大小写的正则匹配速度稍慢，慎用在高频路径上！

第三战：优先级规则——“快递员的VIP通道”

3.1 优先级顺序：从“皇帝”到“平民”

问题：为什么我的正则匹配被前缀匹配覆盖了？

解决方案：牢记 优先级顺序！

# 精确匹配（皇帝级）
location = / {
    root /var/www/html;
}

# 最长前缀匹配（王侯级）
location ^~ /static/ {
    root /var/www/static;
}

# 正则匹配（士大夫级）
location ~ \.php$ {
    proxy_pass http://php_backend;
}

# 普通前缀匹配（平民级）
location / {
    root /var/www/html;
}

注释：

• 优先级顺序：
  1. = 精确匹配
  2. ^~ 最长前缀匹配（停止后续匹配）
  3. ~ 或 ~* 正则匹配（按配置顺序）
  4. 普通前缀匹配（最长匹配）
• 守则：^~ 比正则更优先！

第四战：实战案例——“快递分拣站”的终极挑战

4.1 场景：电商系统的动静分离

需求：

• 静态资源（.css、.js）直接返回，缓存30天。
• API请求（/api/*）反向代理到后端服务。
• 所有其他请求返回 index.html。

解决方案：

# 静态资源：不区分大小写的正则匹配
location ~* \.(css|js|png|jpg|gif)$ {
    root /var/www/static;
    expires 30d;
}

# API请求：最长前缀匹配（优先于正则）
location ^~ /api/ {
    proxy_pass http://backend_api;
}

# 默认请求：普通前缀匹配
location / {
    root /var/www/html;
    index index.html;
}

注释：

• 静态资源优先：用 ~* 匹配图片和样式表，避免被 /api 覆盖。
• API隔离：用 ^~ 确保 /api 不被正则匹配干扰。

第五战：避坑指南——“快递员的防雷手册”

5.1 坑点1：斜杠的“隐形炸弹”

问题：为什么 /api 和 /api/ 会匹配不同的配置？

解决方案：统一路径结尾的斜杠！

# 坑点示例
location /api {
    proxy_pass http://backend_api;  # 匹配 /api 和 /apic
}

location /api/ {
    proxy_pass http://backend_api_v2;  # 仅匹配 /api/
}

# 建议：统一用 ^~ 避免歧义
location ^~ /api {
    proxy_pass http://backend_api;
}

注释：

• 斜杠的玄学：/api 会匹配 /api/123，但 /api/ 只匹配 /api/！
• 最佳实践：用 ^~ 替代普通前缀匹配，避免斜杠陷阱！

5.2 坑点2：正则匹配的“顺序诅咒”

问题：为什么第一个正则匹配的配置总是生效？

解决方案：按优先级排序！

# 错误示例：正则顺序颠倒
location ~ \.jpg$ { ... }  # 会被后面的覆盖！
location ~ \.png$ { ... }  # 实际生效

# 正确示例：按重要性排序
location ~ \.png$ { ... }  # 更重要的匹配放前面
location ~ \.jpg$ { ... }

注释：

• 正则顺序敏感：Nginx会按配置顺序选择第一个匹配的正则！
• 调试技巧：用 curl -I http://example.com/test.png 查看实际匹配的配置。

第六战：高级技巧——“快递员的黑科技”

6.1 使用 map 实现动态路由

问题：想根据路径动态选择后端服务器？

解决方案：用 map 指令！

# 定义变量 $backend，根据路径动态选择后端
map $uri $backend {
    default http://default-backend;
    "~^/xianyang/" http://xianyang-backend;
    "~^/api/" http://api-backend;
}

server {
    listen 80;

    location / {
        proxy_pass $backend;  # 动态选择后端
    }
}

注释：

• map 的魔法：根据 $uri 动态设置 $backend，适合复杂路由场景。
• 性能优势：map 是预处理指令，比 if 更高效！

6.2 使用 try_files 实现优雅降级

问题：想先检查静态文件是否存在，否则返回404？

解决方案：用 try_files！

location / {
    try_files $uri $uri/ /index.html;  # 先找文件，再找目录，最后返回首页
}

注释：

• try_files 的流程：
  1. 检查 $uri 是否存在（如 /about.html）。
  2. 检查 $uri/ 是否存在（如 /about/ 目录）。
  3. 最终返回 /index.html（适合SPA应用）。

常见问题：你问我答

Q：为什么我的 /api 路径匹配了 /apic？
A：

• 因为普通前缀匹配是“最长匹配”，/api 会匹配 /apic！
• 解决方法：用 ^~ /api 替代普通前缀匹配。

Q：如何强制重定向到带斜杠的路径？
A：

• 在配置中添加 location /api { return 301 /api/; }。

Q：正则匹配为什么比前缀匹配优先级低？
A：

• Nginx的设计哲学是“先精确匹配，再正则匹配”，确保最长前缀优先。

结论：成为Nginx的“location大师”

通过本文的七个步骤，你已经掌握了：

1. 精确匹配：= 的“人脸识别”能力。
2. 前缀匹配：普通前缀和 ^~ 的“地址模糊搜索”。
3. 正则匹配：~ 和 ~* 的“魔法滤镜”。
4. 优先级规则：从“皇帝”到“平民”的匹配顺序。
5. 实战案例：电商系统的动静分离配置。
6. 避坑指南：斜杠陷阱和正则顺序诅咒。
7. 高级技巧：map 和 try_files 的“黑科技”。

最后的小彩蛋：
如果你在开发一个“多租户系统”，记得用 map 根据子域名动态选择配置，用 ^~ 隔离公共资源路径！

以上就是Nginx路径匹配的配置指南的详细内容，更多关于Nginx路径匹配的资料请关注脚本之家其它相关文章！

最新评论