深入理解Nginx中Server和Location的匹配逻辑

Server的匹配逻辑

Nginx在决定请求由哪个server块执行时,主要关注的是server块中的listen和server_name两个字段

listen指令

listen字段定义server响应的ip和端口,如果没有明确配置listen字段,默认监听0.0.0.0:80(root)或者0.0.0.0:8080(非root)

listen可以被配置为:

  1. 一个ip和端口的组合
  2. 一个单独的ip,默认监听80端口
  3. 一个单独的端口,默认监听所有的ip接口
  4. 一个Unix socket路径

其中最后一项通常只用于在不同的server之间传递请求

选择要使用的server的规则如下:

  1. Nginx首先将所有"不完整"的listen指令进行转换,比如没有listen字段的转换为listen 0.0.0.0:80,listen 1.1.1.1转换为listen 1.1.1.1:80等
  2. Nginx根据请求的ip和端口创建一个与请求最匹配的server块列表,优先匹配指定了特定ip的server块,其次才会选择listen 0.0.0.0的这种server块.但是无论是哪种情况,端口必须是完全匹配的
  3. 如果只有一个最佳匹配,那么将使用匹配的server块响应请求,否则开始评估每一个server块的server_name指令

再次强调一遍,只有当listen指令无法找到最佳匹配时才会考虑评估server_name指令.

比如,我们假设example.com域名指向了192.168.0.1,且位于192.168.0.1上的nginx有且仅有如下两个server块:

# server block 1server {
  listen 192.168.0.1;
  server_name other.com
  ...
}

# server block 2server {
  listen 80;
  server_name example.com
  ...
}

Server_name指令

如果根据listen指令无法得到最佳匹配,将会开始解析server_name指令.nginx会检查请求中的"Host"头,这个值包含了客户端实际试图请求的域名或者ip地址.nginx会根据这个值去匹配server_name指令,匹配规则如下:

  1. nginx会尝试寻找一个和sever_name和Host值完全匹配的server块,如果找到多个精确匹配,则会使用第一个匹配的server块
  2. 如果没有找到精确匹配的server块,则nginx尝试找到server_name带有*开头的server块,如果找到多个,则选择最长匹配的server块
  3. 如果没有找到使用开头的server块,则会寻找以结尾的server块,同样,如果有多个匹配, 选择最长匹配
  4. 如果没有找到使用*匹配的server块,则会寻找使用正则表达式(以~开头)定义server_name的server块,如果找到多个匹配,会使用第一个匹配
  5. 如果没有找到正则表达式匹配的server块,则nginx将会选择一个匹配listen字段的default server块.每一个ip和端口组合都可以配置一个且只能配置一个默认的default_server块,如果没有的话,则会选择可用列表中的第一个server(此时的选择是随机的,顺序不固定)

示例如下:

(1)准确的server_name匹配,例如:

server {
   listen    80;
   server_name www.domain.com;
   ...
}

(2)以*通配符开始的字符串:

server {
   listen    80;
   server_name *.domain.com;
   ...
}

(3)以*通配符结束的字符串:

server {
   listen    80;
   server_name www.*;
   ...
}

(4)匹配正则表达式:

server {
   listen    80;
   server_name ~^(?.+)\.domain\.com$;
   ...
}

(5)如果以上都没有匹配,则使用default_server.如果没有指定default_server,则会选择第一个可用的server.我们可以指定对于没有匹配的host值时,返回错误到客户端.可以用来防止别人把垃圾流量转到你的网站。

server {
  listen 80  default_server;
  server_name _;  return 444;
}

通过返回444这个nginx的非标准错误码让nginx断开与浏览器的连接

Location的匹配逻辑

Location语法解析

location optional_modifier location_match {
  ...
}

其中可用的modifier修饰符如下

判定规则

1、nginx首先检查基于前缀的location匹配(即不包含正则表达式的匹配)

2、如果有使用=修饰符的location块与请求的URL完全匹配,则立刻使用该location响应请求

3、如果没有找到带有=修饰符的location块匹配,则会继续计算非精确前缀,根据给定的URI找到最长匹配前缀,然后进行如下处理:

(1)如果最长的匹配location带有^~修饰符,nginx立刻使用该location响应请求

(2)如果最长的匹配location不带有^~修饰符,nginx会将该匹配暂时存起来,然后继续后续匹配

4、在确定并储存最长匹配的前缀location块后,nginx继续检查正则表达式匹配location(区分大小写/不区分大小写).如果存在正则表达式满足要求的匹配,则会选择与请求的URI匹配的第一个正则表达式的location来相应请求

5、如果没有找到与请求的URI匹配的正则表达式location,则使用之前存储的最长前缀location响应请求

补充

通常情况下,一旦选择使用某一个location响应请求,那么请求将会在该location内部进行处理,而与其他location无关.但是location中某些指令会触发新的location匹配,比如:

(1)try_files

(2)rewrite

(3)error_page

关于为https配置default_server,参考Properly setting up a “default” nginx server for https

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持我们。

(0)

相关推荐

  • nginx 与后台端口冲突的解决

    问题: 在起alice管理系统的开发环境的时候,发现后台所有的接口在第一次请求的时候全部产生404错误,但第二次请求成功 定位问题 查看nginx 报错日志发现如下报错,因此错误的认为错误发生在html的文件夹权限不够导致的文件无法写入,于是开放权限之后发现还是不行,在Google一番查找还是没找到解决方案.暂时搁置,第二天重新找错时,无意的点开8081端口,当你访问localhost:8081与127.0.0.1:8081的内容竟然不同. 当时发觉是不是端口冲突了,于是打开文件下面是nginx

  • Python实现监控Nginx配置文件的不同并发送邮件报警功能示例

    本文实例讲述了Python实现监控Nginx配置文件的不同并发送邮件报警功能.分享给大家供大家参考,具体如下: 因为项目中经常涉及到多个Nginx之间的配置文件更改,可能回导致最后Nginx之间的配置文件有所不同,这样会对项目产生影响,最典型的就是可能当访问域名解析到其中一台Nginx的时候,可能是正常的,当域名解析到另外一台Nginx的时候,由于配置文件的不同,导致访问出错之类的,影响体验,所以用python写了一个监控配置文件不同的脚本,如果发现不同,就报警,并且以HTML的形式发送邮件指出

  • 使用nginx同域名下部署多个vue项目并使用反向代理的方法

    效果 目前有 2 个项目(project1, project2),还有一个 nginx 自带的 index.html,我添加了对应的链接代码(稍后粘贴出来),为了统一管理子项目的路由. 我期望实现下面的效果(假设 ip: localhost,port: 8080): http://localhost:8080/ 进入最外层的 index.html http://localhost:8080/project1 进入项目一 http://localhost:8080/project2 进入项目二 废

  • CentOS7将Nginx添加系统服务的方法步骤

    导语 经过编译安装以及解决问题,Nginx 已经运行正常,但是此时 Nginx 并没有添加进系统服务.接下来会将 Nginx 添加进系统服务并且设置开机启动. 查看服务 首先查看 Nginx 的服务状态,输入 systemctl status nginx,结果如下 没有找到相关的服务,下一步就是添加系统服务. 添加系统服务 在 /usr/lib/systemd/system 目录中添加 nginx.service,根据实际情况进行修改,详细解析可查看下方参考资料中的文章.内容如下 [Unit]

  • 利用PHP如何统计Nginx日志的User Agent数据

    前言 即将用到爬虫,于是打算收集一下User Agent(UA)数据.接着马上想到自己网站的访问日志不就是现成的优质数据源吗?于是愉快的决定写个脚本统计一下Nginx访问日志中的UA信息. 这类简单操作,用脚本语言就足够,毫无疑问肯定要用最熟悉的PHP.打开vim就开撸,十几分钟下来,功能简单的统计脚本就搞定了. 脚本目前有三个功能: 1. 找出所有的UA信息并排序: 2. 统计操作系统数据: 3. 统计浏览器数据. 程序运行截图如下: 1.UA信息 2.操作系统信息 3.浏览器 用脚本统计最近

  • Nginx开启一个参数就能让你的WEB性能提升3倍的方法

    一.遇到的一些问题 记得 2008 年做性能测试的时候,新进7台 lenovo 4核4G 服务器用于性能测试. 当时资源紧张,这7台服务器都装了双系统(Win2003/CentOS5)空闲时用于做测试机(压测的Agent). 当时给Nginx做了一系列测试,印象很深的是:在这批机器上,Nginx状态页面的压测. 短连接的话最佳QPS约4万,长连接的话最高QPS约13万. 大概3年后,那批 lenovo 服务器已经没人瞧得上了,只能做肉鸡. 然而,一次不经意的测试,发现再牛的服务器,短连接最佳QP

  • Nginx反向代理与负载均衡实战篇

    反向代理 反向代理指的是以代理服务器接收用户的的访问请求,代理用户向内部服务器重新发起请求,最后把内部服务器的响应信息返回给用户.这样,代理服务器对外就表现为一台服务器,而访问内部服务器的客户端用的就是代理服务器,而不是真实网站访问用户. 为什么使用反向代理 可以起到保护网站安全的作用,因为任何来自Internet的请求都必须先经过代理服务器. 通过缓存静态资源,加速Web请求. 实现负载均衡 反向代理例子 环境说明 假如有AB两个服务器.A服务器提供web资源,并且只给内网访问.B服务器有两块

  • Nginx访问控制与参数调优的方法

    Nginx全局变量 Nginx中有很多的全局变量,可以通过$变量名来使用.下面列举一些常用的全局变量: 变量 说明 $args 请求中的参数,如www.123.com/1.php?a=1&b=2的$args就是a=1&b=2 $content_length HTTP请求信息里的"Content-Length" $conten_type HTTP请求信息里的"Content-Type" $document_root nginx虚拟主机配置文件中的roo

  • 详解Django+uwsgi+Nginx上线最佳实战

    什么是uwsgi? uWSGI是一个Web服务器,它实现了WSGI协议.uwsgi.http等协议.Nginx中HttpUwsgiModule的作用是与uWSGI服务器进行交换.WSGI是一种Web服务器网关接口.它是一个Web服务器(如nginx,uWSGI等服务器)与web应用(如用Flask框架写的程序)通信的一种规范. WSGI是一种通信协议. uwsgi是一种线路协议而不是通信协议,在此常用于在uWSGI服务器与其他网络服务器的数据通信.uwsgi协议是一个uWSGI服务器自有的协议,

  • Nginx服务器屏蔽与禁止屏蔽网络爬虫的方法

    每个网站通常都会遇到很多非搜索引擎的爬虫,这些爬虫大部分都是用于内容采集或是初学者所写,它们和搜索引擎的爬虫不一样,没有频率控制,往往会消耗大量服务器资源,导致带宽白白浪费了. 其实Nginx可以非常容易地根据User-Agent过滤请求,我们只需要在需要URL入口位置通过一个简单的正则表达式就可以过滤不符合要求的爬虫请求: location / { if ($http_user_agent ~* "python|curl|java|wget|httpclient|okhttp") {

随机推荐