nginx的server匹配规则

本文介绍了Nginx中server块的匹配规则,包括如何通过listen端口和server_name指令来确定请求应由哪个虚拟主机处理。具体涉及完全匹配、通配符匹配、正则表达式匹配等不同级别的匹配方式及其优先级。

nginx的server匹配规则

nginx的server块可以配置多个,那么一个请求该匹配那个server块呢,这主要是根据server块的server_namelisten来决定的。其中server_name仅仅检查请求的“Host”头以决定该请求应由哪个虚拟主机来处理。

server {
    listen      8001;
    server_name www.baidu.com;
}

server {
    listen      8001;
    server_name *.com;
}

server {
    listen      8001;
    server_name baidu.*;
}

server {
    listen      8001;
    server_name ~^www\.baidu\.com$;
}

server {
    listen      8001 default_server;
    server_name _;
    return 404;
}

相同listen端口的情况下,多个server的匹配顺序如下:

  • 完全匹配优先级最高,匹配则终止
  • 通配符在前的优先级其次,如*.com
  • 通配符在后的优先级次之,如baidu.*
  • 正则匹配优先级最低,如~^www\.baidu\.com$

以上若都没有匹配,那么其会走默认的server,即:

  • 优先选择listen配置项后有default或default_server的server,若没有则:
  • 找到匹配listen端口的第一个server块
<think>嗯,用户这次明确询问了Nginx的通配符匹配规则及示例。结合之前的系统指令,用户需要的是清晰的结构化技术解析,并且特别强调要包含示例。 仔细梳理了所有站内引用,发现几个关键点:引用[3]直接提到了通配符优先级;引用[5]给出了通用配置场景;引用[1][4]则补充了匹配规则分类。用户特意强调"通配符",但Nginx官方术语中实际没有独立"通配符"概念,需要帮用户厘清这个术语在社区通常指代前缀匹配中的星号(*)使用。 用户可能是运维工程师或后端开发者,正在调试Nginx配置。ta没有提供具体配置片段,说明需要的是通用规则讲解。考虑到Nginx配置的易错性,除了基础规则外,还应该包含调试方法和常见陷阱——引用[6]提到的日志调试和引用[5]的优先级混淆案例正好用上。 技术上需要重点区分两种"通配符"形态:一种是路径段匹配如 /images/*.jpg 这样的模式,实际属于正则匹配范畴;另一种是 location /downloads/* 这样的前缀匹配变体。引用[3]的优先级顺序需要前置说明,否则示例可能引发误解。 最后决定采用分层讲解结构:先澄清术语避免混淆,再用表格对比匹配类型(特别标注社区俗称的通配符场景),最后用三个阶梯式示例(基础匹配→正则通配符→陷阱案例)。调试部分特意加入$request_uri变量说明,因为引用[6]显示这是定位优先级问题的关键。 </think>以下是Nginx通配符匹配规则及示例的详细解析,结合匹配优先级和实际场景说明: --- ### 一、通配符匹配规则核心要点 1. **Nginx无独立通配符语法** 严格意义上,Nginx的`location`块不支持类似`*.jpg`的通配符语法,需通过**前缀匹配**或**正则匹配**实现类似功能。 2. **优先级顺序(由高到低)** ```nginx 1. 精确匹配 location = /path # 最高优先级 2. 优先前缀匹配 location ^~ /static/ # 非正则前缀 3. 正则匹配 location ~ \.jpg$ # 区分大小写 location ~* \.png$ # 不区分大小写 4. 普通前缀匹配 location /images/ # 最低优先级前缀 5. 通用匹配 location / # 兜底匹配 ``` --- ### 二、通配符功能实现方式及示例 #### 1. **路径通配符(前缀匹配)** ```nginx # 匹配 /downloads/ 下的任意路径(不含正则) location /downloads/ { add_header Content-Type text/plain; return 200 "匹配所有/downloads/*路径"; } ``` - 示例请求: `/downloads/file.zip` → 匹配 ✅ `/downloads/docs/manual.pdf` → 匹配 ✅ `/downloads` → **不匹配** ❌(缺少尾部`/`) #### 2. **扩展名通配符(正则匹配)** ```nginx # 匹配所有.jpg文件(区分大小写) location ~ \.jpg$ { proxy_pass http://img_server; } # 匹配所有.PNG/.png文件(不区分大小写) location ~* \.png$ { root /data/static; } ``` - 示例请求: `/assets/photo.jpg` → 匹配第一个 ✅ `/icons/LOGO.PNG` → 匹配第二个 ✅ #### 3. **多级路径通配(正则+捕获组)** ```nginx # 匹配 /product/类别/ID 格式的URL location ~ ^/product/(\w+)/(\d+)$ { set $category $1; # 捕获类别 set $product_id $2; # 捕获ID proxy_pass http://api_backend/$category?pid=$product_id; } ``` - 示例请求: `/product/books/123` → 提取 `category=books`, `product_id=123` --- ### 三、通配符使用陷阱与调试 1. **优先级冲突** ```nginx location /static/ { ... } # 普通前缀 location ~ /static/images/ { ... } # 正则 ``` - **问题**:请求 `/static/images/logo.jpg` 会被正则匹配截获,违反预期 - **解决**:对静态路径使用 `^~` 提升优先级 ```nginx location ^~ /static/ { ... } # 优先于正则 ``` 2. **正则性能损耗** - 避免过度使用正则,尤其是 `.*` 宽泛匹配 - 替代方案:用 `map` 或拆分前缀匹配块 3. **调试方法** ```nginx server { error_log /var/log/nginx/debug.log debug; # 开启调试日志 location / { add_header X-Matched $uri; # 响应头显示匹配路径 } } ``` - 日志会显示匹配过程:`"location ~ \.jpg$" matches "/cat.jpg"` --- ### 四、综合示例:API版本路由 ```nginx location = /api/v1/user { ... } # 精确匹配V1接口 location ^~ /api/v2/ { # 优先匹配V2前缀 proxy_pass http://v2_backend; } location ~ /api/(v[3-9])/(\w+) { # 动态匹配更高版本 proxy_pass http://new_backend/$2?version=$1; } location /api/ { # 兜底旧版API proxy_pass http://legacy_backend; } ``` --- ### 相关问题 1. Nginx正则匹配中`~`和`~*`的性能差异有多大? 2. 如何避免正则匹配导致的路径匹配优先级错误? 3. `location`块中使用`if`语句的条件判断有哪些风险? 4. 如何为动态路径(如`/user/{id}`)配置Nginx代理? 5. Nginx调试日志中如何识别匹配失败的location规则? > 引用说明:匹配优先级规则基于Nginx官方文档[^2][^3],通配符实现方式参考实战案例[^1][^5],调试方法来自常见陷阱总结[^1][^4]。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值