参考资料2
参考资料3
主配置文件 /etc/nginx/nginx.conf 。
配置文件中的 path,既可以是绝对路径也可以是相对路径,相对路径相对 /usr/share/nginx 目录。
通过 default_server 参数,指定当前 server 为对应 IP:PORT 对的默认服务器。当一个请求匹配到 IP:PORT,但是 Host 字段不匹配任何一个 server_name,则应用默认服务器 server。假设 http://www.lishiqing.com 请求的 IP:PORT 为 192.168.100.104:80,但是没有对应的 server_name 匹配 www.lishiqing.com ,则应用默认服务器。
如果没有一个 listen 指令具有 default_server 参数,则具有 IP:PORT 对的第一个 server 将是该 IP:PORT 对的默认服务器。
以下配置忽略 server_name,所有指向 192.168.100.105 的域名都能应用该 server
以下配置访问 lishiqing.com 应用默认 server,也就是第一个 server
参考资料
location 指令可以跟字符串,也可以跟正则表达式
location string_path {} 区分大小写的字符串
location = string_path {} 严格匹配字符串
location ~ reg_path {} 区分大小写的正则表达式
location ~* reg_path {} 不区分大小写的正则表达式
http://lishiqing.com/shop/images/1.png 这个请求的 query 为 /shop/images/1.png 。
当 location 后面是字符串的时候,如果某个请求的 query 以该字符串开头,则匹配该 location,比如 /shop/images/1.png 的请求匹配 location /shop {} ,也匹配 location / {} ,但是不匹配 location /blog 。
当 location 后面是正则表达式的时候,如果某个请求的 query 匹配该正则表达式,则匹配该 location,比如 /shop/images/1.png 的请求匹配 location ~ \.(jpg|jpeg|png)$ {} 。
如果某个 query 匹配多个字符串的 location,那么应用匹配度最高的一个 location,与 location 的顺序无关。比如 /shop/images/1.png 的请求匹配 location / {} 和 location /shop {} ,但是应用 location /shop {} 。
如果某个 query 匹配多个正则表达式的 location,那么按照 location 的顺序应用第一个匹配的 location。比如 /shop/images/1.png 的请求匹配 location ~ \.(jpg|jpeg|png)$ {} 和 location ~ .*/images/.* {} ,但是应用第一个匹配的 location ~ \.(jpg|jpeg|png)$ {} 。因为在 query 在检查正则表达式的时候,遇见第一匹配的 location 就停止继续查找了。
如果某个 query 既匹配某个字符串的 location,又匹配某个正则表达式的 location,那么应用正则表达式的 location,与顺序无关。比如 /shop/images/1.png 的请求匹配 location /shop {} 和 location ~ \.(jpg|jpeg|png)$ {} ,但是会应用 location ~ \.(jpg|jpeg|png)$ {} 。这是因为某个请求会先检查跟着字符串的 location,不管是否找到匹配的字符串 location,都会继续按照顺序查找跟着正则表达式 location,因此正则表达式的优先级高于字符串。如果找到了匹配的正则表达式,则立即停止查找,应用该 location,如果没找到匹配的正则表达式,则应用刚才找到的匹配度最高的字符串 location。
location = string_path {} 为严格匹配,query 必须与 string_path 完全一致才能匹配。如果 query 与某个 = string_path 匹配,则立即停止查找,应用该 location。意味着不会去查找正则表达式 location。比如 /shop/images/1.png 匹配 location = /shop/images/1.png {} ,不匹配 location = /shop {} 和 location = /shop/images 。一般用来设置 location = / {} 来匹配 / 的 query,因为 / 的 query 会很频繁,因此将 location = / {} 放在第一条 location 可以提高匹配查询的效率。
location ^~ string_path {} 这种字符串匹配的优先级高于正则表达式,当某个 query 匹配该 location 的时候,不会继续查找正则表达式的 location 了。比如 /shop/images/1.png 的 query 满足 location ^~ /shop {} 和 location ~ \.(jpg|jpeg|png)$ {} ,但是会应用 location ^~ /shop {} 。
总结:
配置文件名为 nginx.conf ,Linux放在目录: /usr/local/nginx/conf 、 /etc/nginx , 或 /usr/local/etc/nginx 中;Windows放在 安装目录\conf 中。 依据实际安装情况决定
nginx由配置文件中指定的指令控制模块组成。 指令分为 简单指令 和 块指令 :
简单指令 由空格分隔的名称和参数组成,并以分号 结尾;
块指令 具有与简单指令相同的结构,但是是以大括号 { 和 } 包围的一组附加指令。 如果块指令在大括号内部有其他指令,则称为上下文(例如: events , http , server 和 location );
配置文件中放置在任何上下文之外的伪指令都被认为是主上下文。 events 和 http 指令驻留在主上下文中, server 在 http 中的,而 location 在 server 块中。一个配置文件一个 http ,一个及以上个 server ,一个 server 运行一个工作进程并代表一个虚拟服务器;
# 号所在的一行被视为注释;
几个顶级指令将适用于不同流量类型的指令组合在一起:
对于大多数指令,在子上下文中定义的上下文将继承父级中包含的伪指令的值,要覆盖从父进程继承的值,子上下文中需要包含该指令(即子上下文要显式声明)。
打开配置文件(如 /usr/local/nginx/conf/nginx.conf ),默认的配置文件已经包含了服务器块的几个示例,大部分是注释掉的。 现在注释掉所有这样的块,并启动一个新的服务器块:
每个 server 上下文都可以指定要监听的端口、server_name,当nginx决定哪个服务器处理请求后,它会根据服务器块内部定义的location指令的参数测试请求头中指定的URI, 比如如下配置,系统中创建 /data 目录及其子目录 /www :
第一个 location 块指定与请求中的URI比较 / 前缀。 对于匹配请求,URI将被添加到 root 指令中指定的路径(即 /data/www ),形成本地文件系统中的请求文件路径。 如果有几个匹配的location块,nginx将选择具有最长前缀来匹配location块。 上面第一个 location 块提供最短的前缀长度为1,因此只有当所有其他location块不能提供匹配时,才会使用该块。第二个 location ,将是以 /images/ 的请求来匹配,位置 / 也匹配这样的请求,但具有较短前缀,也就是 /images/ 比 / 长。
这已经是一个在标准端口 80 上侦听并且可以在本地机器上访问的服务器 http://localhost/ 的工作配置, 端口 80 和 server_name localhost 可以省略,它们为默认值 。 响应以/images/开头的URI的请求,服务器将从 /data/images 目录发送文件。 例如,响应 http://localhost/images/logo.png 请求,nginx将发送服务上的 /data/images/logo.png 文件。 如果文件不存在,nginx将发送一个指示 404 错误的响应。 不以 /images/ 开头的URI的请求将映射到 /data/www 目录。 例如,响应 http://localhost/about/example.html 请求时,nginx将发送 /data/www/about/example.html 文件。
反向代理应该是Nginx做的最多的一件事了,反向代理(Reverse Proxy)方式是指以代理服务器来接受internet上的连接请求,然后将请求转发给内部网络上的服务器,并将从服务器上得到的结果返回给internet上请求连接的客户端,此时代理服务器对外就表现为一个反向代理服务器。简单来说就是真实的服务器不能直接被外部网络访问,所以需要一台代理服务器,而代理服务器能被外部网络访问的同时又跟真实服务器在同一个网络环境,当然也可能是同一台服务器,端口不同而已。
通过向nginx配置文件添加一个server块来定义代理服务器,其中包含以下内容:
这将是一个监听端口 8080 的简单服务器,并将所有请求映射到本地文件系统上的 /data/up1 目录。 请注意,root指令位于server块上下文中,当选择用于服务请求的 location 块不包含自己的 root 指令时,将使用此root指令。创建 /data/up1 目录然后可以将一个静态网页比如 index.html 文件放入其中,然后访问 http://localhost:8080/ 即可访问该文件。
目前为止,还是配置的静态资源访问,并不是代理服务器,然后增加或修改现有 location 上下文,改为如下:
当用户访问 http://localhost:8080/ 时,会返回 http://localhost:8181 服务器的的资源。
location 上下文后面的参数,可以是正则表达式,如果是正则表达式,前面要加 ~ ,比如:
以上配置表示,nginx接收到所有以.gif,.jpg或.png结尾的URI,相应的请求将映射到/data/images目录。当nginx选择一个location块来提供请求时,它首先检查指定前缀的location指令,记住具有最长前缀的location,然后检查正则表达式。 如果与正则表达式匹配,nginx会选择此location,否则选择之前记住的那一个。
要找到最符合URI的位置,NGINX首先将URI与前缀字符串的位置进行比较。然后用正则表达式搜索位置。除非使用^~修饰符对正则表达式给予更高的优先级。在前缀字符串中,NGINX选择最具体的字符串(也就是最长和最完整的字符串)。 下面给出了选择处理请求的位置的确切逻辑:
测试所有URI的前缀字符串。 = (等号)修饰符定义了URI和前缀字符串完全匹配。如果找到完全匹配,则搜索停止。如果 ^~ (插入符号)修饰符预先添加最长匹配前缀字符串,则不会检查正则表达式。存储最长匹配的前缀字符串。根据正则表达式测试URI。断开第一个匹配的正则表达式并使用相应的位置。如果没有正则表达式匹配,则使用与存储的前缀字符串相对应的位置。
= 修饰符的典型用例是 / (正斜杠)的请求。 如果请求/是频繁的,则指定 = / 作为location指令的参数加速处理,因为搜索匹配在第一次比较之后停止。
要启动nginx,请运行可执行文件。 当nginx启动后,可以通过使用-s参数调用可执行文件来控制它。 使用以下语法:
信号(signal)的值可能是以下之一:
当主进程收到要重新加载配置的信号,它将检查新配置文件的语法有效性,并尝试应用其中提供的配置。 如果这是成功的,主进程将启动新的工作进程,并向旧的工作进程发送消息,请求它们关闭。 否则,主进程回滚更改,并继续使用旧配置。 老工作进程,接收关闭命令,停止接受新连接,并继续维护当前请求,直到所有这些请求得到维护。 之后,旧的工作进程退出。
两者在 location 中,指定一个路径,其中使用 alias 做如下配置:
若按照上述配置的话,则访问/img/目录里面的文件时,ningx会自动去/var/www/image/目录找文件
若按照这种配置的话,则访问/img/目录下的文件时,nginx会去/var/www/image/img/目录下找文件。alias是一个目录别名的定义,root则是最上层目录的定义,指的是 /var/www/image/img/ 。还有一个重要的区别是alias后面必须要 / 结束,否则会找不到文件,而root则可有可无。
另外对于index,含义如下
这样,当用户请求 / 地址时,Nginx 就会自动在 root 配置指令指定的文件系统目录下依次寻找 index.htm 和 index.html 这两个文件。如果 index.htm 文件存在,则直接发起“内部跳转”到 /index.htm 这个新的地址;而如果 index.htm 文件不存在,则继续检查 index.html 是否存在。如果存在,同样发起“内部跳转”到 /index.html ;如果 index.html 文件仍然不存在,则放弃处理权给 content 阶段的下一个模块。
参考地址1
参考地址2:B站
一个典型的nginx配置文件是由一系列的server块组成。而每个server块是有一系列的location块组成。server块是nginx从逻辑上划分出来的一个个的虚拟服务器,可以从逻辑上认为你的服务器变成多个了。block块定义了一个url路径该如何定位到正式的文件。总体来说,nginx处理一个请求的时候,先根据(ip地址,port端口,domain域名)来确定下由哪一个server块来进行处理,然后server块再根据请求的地址来进行location块的挑选,location块内部的规则最终确定下这个请求怎么返回(直接返回文件内容,还是映射成其他请求,还是传给其他服务执行)。
如果我们访问链接 http://lab.example.com:80/cs/image.jpg 那么就会由第一个server的第二个location来处理。流程是什么样的呢:
这样就完成了一个完整的链接请求。
server块最重要的两个属性是listen和server_name。当请求来临时,listen属性先用来匹配,如果匹配到唯一server块那么就是这个server块进行服务(就不用考虑server_name是否匹配上了);如果匹配不是唯一的,那么就继续使用server_name进行匹配。
当两个表达带通配符的形式相同的时候,匹配最长的那个。
语法中的optional_modifier是描述符,location_match是具体匹配的串形式,如果描述符是正则的一种,那么就会以正则的方式来对待location_match,否则以普通方式用location_match来当前缀匹配。
|类型|含义|匹配方式|优先级|例子|
|:--|:--|:--|:--|
|(none)|最普通的前缀匹配|前缀方式匹配|4|location / {}|
|=|要求绝对相等|前缀方式匹配|1|location = /image {}|
|~|区分大小写的正则匹配|正则方式匹配|3|location ~ .(jpe?g)$ {}|
|~ |不区分大小写的正则匹配|正则方式匹配|3|location ~ .(jpe?g)$ {}|
|^~|高优先级的前缀匹配|前缀方式匹配|2|location ^~ /page {}|
如果我们要匹配\big\middle\small的话,是不会匹配到 location ^~ \big\middle {...} 这条规则的,因为当=规则匹配结束没找到之后,就回去找(none)和^~中匹配最长的一条,这时候最长的是(none)的 location \big\middle\small {...} ,然后在进行正则匹配,发现没有满足的,于是就取(none)的这一条了。这一点要注意。
在上述步骤后,我们知道一个请求具体定位到location的过程,现在来继续探究location之后的相应处理。首先是location中的资源应该对应在哪一个服务器目录中呢?这就需要root属性来指定了。
root属性可以定义在server块中,也可以定义在location块中。如果声明在server块中那么所有的location都会继承这个定义。同时若location中也定义了root属性,那么以location中的定义为主。
举个例子
如果访问/cs/vr/audio.mp3,那么就会对应到服务器上的/share/usr/cs/vr/audio.mp3的资源
如果访问/eg/file/new.pdf,那么就会对应到服务器上的/var/www/html/eg/file/new.pdf的资源
再比如用nginx上架设codeigniter框架,我们需要重写url那么我们这样
那么这样,对于一个非.php的文件,都为在第一个location中重写成/index.php?$uri的形式重写进行一次搜索。这时候必然被第二个location接收(前缀匹配的更长嘛),这样就完成了codeigniter的定位。
比如我们访问 ci.example.com/hello 就会被重定向到访问var/www/example/index.php?hello同时被pass给php的cgi进行处理。
Understanding Nginx Server and Location Block Selection Algorithms
how-to-configure-nginx
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)