1 什么是nginx
Nginx,也被称为"engine x",是一个开源且高性能的HTTP和反向代理web服务器。它同时也提供了IMAP/POP3/SMTP服务。Nginx最初是由伊戈尔·赛索耶夫为俄罗斯访问量第二的Rambler.ru站点开发的,并在2004年10月4日发布了首个公开版本。
Nginx具有几个显著的特性:首先,它具有较快的响应速度,无论是单次请求还是高并发环境下,都能比其他web服务器提供更快的响应。其次,Nginx基于模块化设计,由多个耦合度极低的模块组成,因此具有很高的扩展性。此外,其可靠性来自于核心框架代码的优秀设计和模块设计的简单性。如果一个worker进程出错,master进程可以快速拉起新的worker子进程提供服务。最后,Nginx因其稳定性、丰富的功能集、简单的配置文件和低系统资源的消耗而闻名。
2 正向代理与反向代理
2.1 正向代理
2.1.1 概念
正向代理是指客户端通过代理服务器向互联网发送请求。当客户端需要访问某个目标服务器时,它首先将请求发送给正向代理服务器,然后由正向代理服务器代表客户端向目标服务器发送请求。目标服务器响应请求后,正向代理服务器再将响应返回给客户端。
2.1.2 特点
-
客户端知道代理服务器的存在,并将请求发送给代理服务器。
-
代理服务器与目标服务器进行通信,隐藏了客户端的真实IP地址。
-
适用于客户端需要访问受限制的资源或需要匿名访问的场景。
2.2反向代理
2.2.1 概念
反向代理是指服务器接收来自互联网的请求,并将其转发到内部服务器上。当互联网上的用户请求访问某个资源时,请求首先被发送到反向代理服务器,然后反向代理服务器根据请求的内容将请求转发到内部的服务器上。内部服务器处理请求后,将响应返回给反向代理服务器,最后反向代理服务器将响应返回给用户。
2.2.2 特点
-
互联网上的用户不知道内部服务器的存在,只知道反向代理服务器的地址。
-
反向代理服务器负责负载均衡、缓存、SSL终止等功能。
-
适用于多个内部服务器提供相同服务的场景,可以提高系统的可扩展性和安全性。
2.3正向代理和反向代理的异同
2.3.1 相同点
正向代理和反向代理所处的位置都是客户端和真实服务器之间,所做的事情也都是把客户端的请求转发给服务器,再把服务器的响应转发给客户端。
2.3.2 不同点
-
角色不同:正向代理是客户端的代理,而反向代理是服务器的代理。
-
请求方向不同:正向代理是将客户端的请求转发到目标服务器,而反向代理是将互联网上的请求转发到内部服务器。
-
IP地址隐藏:正向代理可以隐藏客户端的真实IP地址,而反向代理可以隐藏内部服务器的真实IP地址。
-
应用场景不同:正向代理适用于客户端需要访问受限制的资源或需要匿名访问的场景,而反向代理适用于多个内部服务器提供相同服务的场景。
2.4.通过故事理解正向代理和反向代理
2.4.1 正向代理
同学A急需一笔钱,他直接向富豪马云借钱,但是他俩之间毫无关系,结果当然是没有借到。经过一番打听,同学A的老师王先生是马云的好朋友,于是A同学请求王老师,让王老师帮忙向马云借钱,最终马云同意借钱给王老师,王老师把这笔钱转交给了A同学。
上文就相当于一个正向代理的过程,A同学为客户端,马云为服务器,王老师为正向代理。A同学请求王老师向马云借钱,这个过程中A同学隐藏了自己的角色,马云事实上是不知道到底是谁借的钱。相当于服务器不知道真正发起请求的客户端是谁。
2.4.2 反向代理
如果遇到困难需要拨打10086客服电话,可能一个地区的10086客服有几十个,但是我们不需要关心电话那头的人是谁。只需要拨通10086的总机号码,电话那头总有客服会回应。
这里的10086总机号码就相当于反向代理,客户端不知道真正提供服务的人是谁
3 nginx的安装
1)去nginx news下载对应的nginx包,推荐使用稳定版本
2)上传nginx到linux系统
3)安装依赖环境
//安装gcc环境 yum install gcc-c++ //安装PCRE库,用于解析正则表达式 yum install -y pcre pcre-devel //zlib压缩和解压缩依赖 yum install -y zlib zlib-devel //SSL 安全的加密的套接字协议层,用于HTTP安全传输,也就是https yum install -y openssl openssl-devel
4)解压,需要注意,解压后得到的是源码,源码需要编译后才能安装
tar -zxvf nginx-1.16.1.tar.gz
5)编译之前,先创建nginx临时目录,如果不创建,在启动nginx的过程中会报错
mkdir /var/temp/nginx -p
6)在nginx目录,输入如下命令进行配置,目的是为了创建makefile文件
./configure \ --prefix=/usr/local/nginx \ --pid-path=/var/run/nginx/nginx.pid \ --lock-path=/var/lock/nginx.lock \ --error-log-path=/var/log/nginx/error.log \ --http-log-path=/var/log/nginx/access.log \ --with-http_gzip_static_module \ --http-client-body-temp-path=/var/temp/nginx/client \ --http-proxy-temp-path=/var/temp/nginx/proxy \ --http-fastcgi-temp-path=/var/temp/nginx/fastcgi \ --http-uwsgi-temp-path=/var/temp/nginx/uwsgi \ --http-scgi-temp-path=/var/temp/nginx/scgi
注: 代表在命令行中换行,用于提高可读性
配置命令:
命令 | 解释 |
---|---|
–prefix | 指定nginx安装目录 |
–pid-path | 指向nginx的pid |
–lock-path | 锁定安装文件,防止被恶意篡改或误操作 |
–error-log | 错误日志 |
–http-log-path | http日志 |
–with-http_gzip_static_module | 启用gzip模块,在线实时压缩输出数据流 |
–http-client-body-temp-path | 设定客户端请求的临时目录 |
–http-proxy-temp-path | 设定http代理临时目录 |
–http-fastcgi-temp-path | 设定fastcgi临时目录 |
–http-uwsgi-temp-path | 设定uwsgi临时目录 |
–http-scgi-temp-path | 设定scgi临时目录 |
7)make编译
//编译 make //安装 make install
至此,nginx已安装完毕!!!
8)进入sbin目录
//启动 ./nginx //停止 ./nginx -s stop //重新加载 ./nginx -s reload //检查配置文件的正确性 ./nginx -t
打开浏览器,访问虚拟机所处内网ip即可打开nginx默认页面,显示如下便表示安装成功:
注意事项:
-
如果在云服务器安装,需要开启默认的nginx端口:80
-
如果在虚拟机安装,需要关闭防火墙
-
本地win或mac需要关闭防火墙
4 nginx解析默认首页流程
-
Nginx接收到客户端发送的HTTP请求。
-
Nginx根据配置文件(通常为
/etc/nginx/nginx.conf
)中定义的虚拟主机或服务器块来确定要处理该请求的位置。 -
Nginx查看请求的URL路径部分,并与配置文件中指定的root目录相结合,构建完整的文件路径。
-
Nginx使用内置的文件系统模块对文件路径进行解析,判断所需的文件是否存在。如果不存在,则返回404错误;如果存在,则将其加载到内存中。
-
Nginx根据文件类型、MIME类型等信息,选择正确的处理程序来处理这个文件。
-
如果文件是HTML文件,那么Nginx会调用内置的ngx_http_index_module模块来解析默认首页。
-
ngx_http_index_module模块会优先查找名称为"index.html"的文件,然后再查找"default.htm"等可能的默认首页文件。
-
当找到了符合条件的默认首页文件时,Nginx会将其传输给客户端。
-
若没有找到任何默认首页文件,Nginx会返回403 Forbidden错误。
server { listen 80; server_name localhost; #access_log logs/host.access.log main; location / { root html; index index.html index.htm; } location = /50x.html { root html; } 解释: 1.server 用于监听某个端口 2.listen 表示监听80端口 2.server_name 表示请求的ip地址,根据ip地址找到server 3.location 表示映射 4.root 表示根 ,html 文件夹为conf的相对目录 /映射到root里面找到相应的文件夹,html; 5.index 为配置默认的首页
5 nginx的进程模型
Nginx的进程模型采用了一种典型的master-worker方式。具体来说,它主要包括以下几个部分:
5.1 master进程
Master Process (监控进程或主进程): 主进程主要负责管理worker进程。它的功能包括接收来自外界的信号、向各worker进程发送信号、监控worker进程的运行状态。当worker进程因为异常情况退出后,master进程会自动重新启动新的worker进程。此外,master进程也充当整个进程组与用户的交互接口,同时对进程进行监护。
5.2 worker进程
Worker Processes (工作进程):
由master进程fork而来。由于每个进程都一样,所以每个 Worker 都有 Master 创建出来的 listen 状态的 socket 句柄。所以每个worker进程都能监听到新连接加入的事件。 worker进程负责具体的网络请求的处理 worker之间的关系是平等的,同等的竞争来自客户端的请求,并且互相独立。 一个请求只能在一个worker中进行处理,一个worker也不可能处理其他worker的请求 worker进程个数是可配置的,一般与机器cpu核心数量一致。
6 nginx的请求机制
6.1 web与client的交互方式
从设计架构来说,Nginx服务器是与众不同的。不同之处一方面体现在它的模块化设计,另一方面,也是最重要的一方面,体现在它对客户端请求的处理机制上。
Web服务器和客户端是一对多的关系,Web服务器必须有能力同时为多个客户端提供服务。一般来说,完成并发处理请求工作有三种方式可供选择、多进程、多线程、异步方式。
6.1.1 多进程方式
多进程方式是指,服务器每当接收到一个客户端时,就由服务器主进程生成一个子进程出来和该客户端建立连接进行交互,直到连接断开,改子进程就结束了。
多进程方式的优点在于,设计和实现相对简单,各个子进程之间相互独立,处理客户端请求的过程彼此不受到干扰,并且当一个子进程产生问题时,不容易将影响蔓延到其他进程中,这保证了提供服务的稳定性。当子线程退出时,其占用资源会被操作系统回收,也不会留下任何垃圾。而其缺点也很明显。操作系统中生成一个子进程需要进行内存复制等操作,在资源和时间上回产生一定的额外开销,因此,如果Web服务器接收大量并发请求,就会对系统资源造成压力,导致系统性能下降。
初期的Apache服务器就是采用这种方式对外提供服务的。为了应对大量并发请求,Apache服务器采用“预生成进程”的机制对多进程方式进行改进,“预生成进程”的工作方式很好理解。它将生成子进程的时机提前,在客户端请求还没有到来之前就预先生成好,当请求到来时,主进程分配一个子进程和该客户端进行交互,交互完成之后,该进程也不结束,而被主进程管理起来等待下一个客户端请求的到来,改进的多进程方式在一定程度上缓解了大量并发请求情形下Web服务器对系统资源造成的压力。但是优化Apache服务器在最初的构架设计上采用了多进程方式,因此这不能从根本上解决问题。
6.1.2 多线程方式
多线程方式和多进程方式相似,他是指,服务器每接收到一个客户端时,会有服务器主进程派生一个线程出来和该客户端进行交互。
由于操作系统产生一个线程的开销远远小于产生一个进程的开销,所以多线程方式在很大程度上减轻了Web服务器对系统资源的要求。该方式使用线程进行任务调度,开发方面可以遵循一定的标准,这相对来说比较规范和有利于协作。但在线程管理方面,改方式有一定的不足。多个线程位于同一个进程内,可以访问同样的内存空间,彼此之间相互影响;同时,在开发过程中不过避免地要开发者自己对内存进行管理,其增加了出错的风险。服务器系统需要长时间连续不停地运转,错误的逐渐积累可能最终对整个服务器产生重大影响。
IIS服务器使用了多线程方式对外提供服务,它的稳定性相对来说还是不错的,但对于经验丰富的Web服务器管理人员而言,他们通常还是会定期检查和重启服务器,以预防不可预料的故障发生。
6.1.3异步方式
异步方式是和多进程方式及多线程方式完全不同的一种处理客户端请求的方式。在介绍改方式之前 ,我们先复习下同步、异步以及阻塞、非阻塞的概念。
网络通信中的同步机制和异步机制是描述通信模块的概念。同步机制,是指发送方发送请求后,需要等待接收到接收方发回的响应后,才接着发送下一个请求;异步机制,和同步机制正好相反,在异步机制中,发送方发出一个请求后,不等待接收方响应这个请求,就继续发送下个请求。在同步机制中,所有的请求在服务器端得到同步,发送方和接收方对请求的处理步调是一致的;在异步机制中,所有来着发送方的请求形成一个队列,接收方处理完成后通知发送方。
阻塞和非阻塞用来描述进程处理调用的方式,在网络通信中,主要指网络套接字Socket的阻塞和非阻塞方式,而Socket的实质也是IO操作,Socket的阻塞调用方式为,调用结果返回之前,当前线程从运行状态被挂起,一直等到调用结果返回之后,才进行就绪状态,获取CPU后继续执行;Socket的非阻塞调用方式和阻塞方式调用方式正好相反,在非阻塞方式中,如果调用结果不能马上返回,当前线程也不会被挂起,而是立即返回执行下一个调用。
在网络通信中,经常可以看到有人讲同步和阻塞等同、异步和非阻塞等同。事实上,这两对概念有一定的区别,不能混淆。两对概念的组合,就会产生四个新的概念,同步阻塞、异步阻塞、同步非阻塞、异步非阻塞。
-
同步阻塞方式,发送方向接收方发送请求后,一直等待响应;接收方处理请求是进行的IO操作如果不能马上得到结果,就一直等到返回结果后,才响应发送方,期间不能进行其他工作。比如、在超时排队付账时,客户(发送方)想收款员(接收方)付款(发送请求)后需要等待收款员找零,期间不能做其他的事情;而收款员要等待收款机返回结果(IO操作)后才能把零钱取出来交给客户(响应请求),期间也只能等待,不能做其他的事情。这种方式实现简单,但是效率不高。
-
同步非阻塞方式,发送方向接收方发送请求后,一直等待响应;接收方处理请求时进行的IO操作如果不能马上得到结果,就立即返回,去做其他事情,但由于没有得到请求处理结果,不响应发送方,发送方一直在等待,一直等IO操作完成后,接收方获得结果响应发送方后,接收方才进入下一次请求过程。在实际中不使用这种方式。
-
异步阻塞方法,发送方向接收方发送请求后,不用等待响应,可以继续其他工作;接收方处理请求是进行的IO操作如果不能马上得到结果,就一直等到返回结果后,才响应发送方,期间不能进行其他工作。这种方式在实际中也不使用。
-
异步非阻塞方式,发送方向接收方发送请求后,不用等待响应,可以继续其他工作;接收方处理请求时进行的IO操作富国不能马上得到结果,也不等待,而是马上返回去做其他事情。当IO操作完成以后,将完成状态和结果通知接收方,接收方再响应发送方。继续使用在超市付账排队的例子。客户(发送方)想收款员(接收方)付款(发送请求)后在等待收款员找零的过程中,还可以做其他事情,比如打电话、聊天等;而收款员在等待收款机处理交易(IO操作)的过程中可以帮助客户将商品打包,当收款机产生结果后,收款员给客户结账(响应请求)。在四种方式中,这种方式是发送方和接收方通信效率最高的一种。
6.2Nginx如何处理请求
Nginx服务器的一个显著优势是能够同时处理大量并发请求。它结合多进程机制和异步机制对外提供服务,异步机制使用的是异步非阻塞方式
Nginx服务器启动后,可以产生一个主进程(master process)和多个工作进程(worker processes),其中可以在配置文件中指定产生的工作进程数量。Nginx服务器的所有工作进程都用于接收和处理客户端的请求。这类似于Apache使用的改进的多进程机制,预先生成多个工作进程,等待处理客户端请求。
每个工作进程使用了异步非阻塞方式,可以处理多个客户端请。当某个工作进程接收到客户端的请求以后,调用IO进行处理,如果不能立即得到结果,就去处理其他的请求;儿客户端在此期间业务需等待响应,可以去处理其他的事情;当IO调用返回结果时,就会通知此工作进程;该进程的到通知,暂时挂起当前处理的事务,去响应客户端请求。
客户端请求数量增长、网络负载繁重时,Nginx服务器使用多进程机制能够保证不增长对系统资源的压力;同时使用异步非阻塞方式减少了工作进程在I/O调用上的阻塞延迟,保证了不降低对请求的处理能力。
6.3 Nginx事件驱动处理模型
在上面我们提到,Nginx服务器的工作进程调用IO后,就去进行其他工作了;当IO调用返回后,会通知工作进程。这里有一个问题,IO调用时如何把自己的状态通知给工作进程的呢?
一般解决这个问题的方案有两种。一是,让工作进程在进行其他工作的过程中间隔一段时间就去检查一下IO 的运行状态,如果完成,就去响应客户端,如果未完成,就继续在进行的工作;二是,IO调用在完成后能主动通知工作进程。对于前者,虽然工作进程在IO调用过程中没有等待,但不断的检察仍然在时间和资源上导致了不小的开销,最理想的解决方案就是第二种。
具体来说,select/pool/epool/kqueue等这样的系统调用就是用来支持第二种解决方案的。这些系统调用,也常被称为事件驱动模型,他们提供了一种机制,让进程可以同时处理多个并发请求,不用关心IO调用的具体状态,IO调用完全由事件驱动模型来管理,事件准备好之后就通知工作进程事件已经就绪。
事件驱动处理库有被称为多路IO复用方法,最常见的包括以下三种:select模型、poll模型和epoll模型。
6.3.1 select库
select库,是各个版本的Linux和Windows平台都支持的基本事件驱动模型库,并且在接口的定义上也基本相同,只是部分参数的含义略有差异。使用select库的步骤一般是:
首先,创建所关注事件的描述符集合。对于一个描述符,可以关注其上面的读(Read)事件、写(Write)事件以及异常发生(Exception)事件,所以要创建三类事件描述集合,分别用来收集读事件的描述符、写事件的描述符和异常事件的描述符。
其次,调用底层提供的select()函数,等待事件发生。这里需要注意的一点是,select的阻塞与是否设置非阻塞I/O是没有关系的。
然后,轮询所有事件描述符集合中的每个事件描述符,检查是否有相应的事件发生,如果有,就进行处理。
Nginx服务器在编译过程中如果没有为其他指定其他高性能事件驱动模型库,它将自动编译该库。我们可以使用--with-select_module和--without-select_module两个参数强制Nginx是否编译该库。
6.3.2 poll库
poll库,作为Linux平台上的基本事件驱动模型,是在Linux2.1.23中引入。Windwos平台不支持poll库。
poll与select的基本工作方式是相同的,都是先创建一个关注事件的描述符集合,再去等待这些事件的发生,然后再轮询描述符集合,检查有没有事件发生,如果有,就进行处理。
poll库与select库的主要区别在于,select库需要为读事件、写事件和异常事件分别创建一个描述符集合,因此在最后轮询的时候,需要分别轮询这三个集合。而poll库只需要创建一个集合,在每个描述符对应的结构上分别设置读事件、写事件或者异常事件,最后轮询的时候,可以同时检查者三种事件是否发生。可以说,poll库是select库的优化实现。
Nginx服务器在编译过程中如果没有为其制定其他高性能事件驱动模型库,它将自动编译该库。我们可以使用--with-poll_module和--without-poll_module两个参数强制Nginx是否编译该库
6.3.3 epoll库
epoll库是Nginx服务器支持的是高性能事件驱动库之一,它是公认的非常优秀的事件驱动模块,和poll库及select库有很大的不同。epoll属于poll库的一个变种,是在Linux2.5.44中引入的,在Linux2.6及以上的版本都可以使用它。poll库和select库在实际工作中,最大的区别在于效率。
从前面的介绍我们知道,它们的处理方式都是创建一个待处理事件列表,然后把这个列表发给内核,返回的时候,再去轮询检查这个列表,以判断事件是否发生。这样在描述符比较多的应用中,效率就显得比较低下了。一种比较好的做法是,把描述符列表的管理交由内核负责,一旦有某种事件发生,内核把发生时间的描述符列表通知给进程,这样就避免了轮询整个描述符列表。epoll库就是这样一种模型。
首先,epoll库通过相关调用通知内核创建一个有N个描述符的事件列表;然后,给这些描述符设置锁关注的事件,并把它添加到内核的事件列表中去,在具体的编码过程中也可通过相关调用对时间列表中描述符进行修改和删除。
完成设置之后,epoll库就开始等待内核通知事件发生了。某一事件发生后,内核讲发生事件的描述符列表上报给epoll库。得到时间列表的epoll库,就可以进行事件处理了。
epoll库在Linux平台上是高效的。它支持一个进程打开大数目的时间描述符,上限是系统可以打开文件的最大数目;同时,epoll库的IO效率不随描述符数目增加而线性下降,因为它只会对内核上报的“活跃”的描述符进行操作
7 nginx配置文件解析
Nginx安装完毕后,会产生相应的安装目录,根据前面的安装路径,Nginx的配置文件路径为 /usr/local/nginx/conf
其中 nginx.conf
为Nginx的主配置文件
这里重点介绍下 nginx.conf
这个配置文件。
7.1 组成
Nginx配置文件默认有6个部分组成:分别是main、events、http、server、upstream和location
其中:
-
main部分设置的指令将影响其他所有设置;
-
events部分用来配置影响nginx服务器或与用户的网络连接;
-
http部分可以嵌套多个server,主要用来配置代理,缓存,自定义日志格式等绝大多数功能和第三方模块的配置,
-
server部分用于配置虚拟主机的相关参数;
-
location部分用于配置请求的处理规则,以及各种页面的处理情况
-
upstream用于部署集群、内网服务器
-
-
7.2 参数解析
# main段配置信息 user nginx; # 运行用户,默认即是nginx,可以不进行设置 worker_processes auto; # Nginx 进程数,一般设置为和 CPU 核数一样 error_log /var/log/nginx/error.log warn; # Nginx 的错误日志存放目录 pid /var/run/nginx.pid; # Nginx 服务启动时的 pid 存放位置 # events段配置信息 events { use epoll; # 使用epoll的I/O模型(如果你不知道Nginx该使用哪种轮询方法,会自动选择一个最适合你操作系统的) worker_connections 1024; # 每个进程允许最大并发数 } # http段配置信息 # 配置使用最频繁的部分,代理、缓存、日志定义等绝大多数功能和第三方模块的配置都在这里设置 http { # 设置日志模式 log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; # Nginx访问日志存放位置 sendfile on; # 开启高效传输模式 tcp_nopush on; # 减少网络报文段的数量 tcp_nodelay on; keepalive_timeout 65; # 保持连接的时间,也叫超时时间,单位秒 types_hash_max_size 2048; include /etc/nginx/mime.types; # 文件扩展名与类型映射表 default_type application/octet-stream; # 默认文件类型 include /etc/nginx/conf.d/*.conf; # 加载子配置项 # server段配置信息 server { listen 80; # 配置监听的端口 server_name localhost; # 配置的域名 # location段配置信息 location / { root /usr/share/nginx/html; # 网站根目录 index index.html index.htm; # 默认首页文件 deny 172.168.22.11; # 禁止访问的ip地址,可以为all allow 172.168.33.44;# 允许访问的ip地址,可以为all } error_page 500 502 503 504 /50x.html; # 默认50x对应的访问页面 error_page 400 404 error.html; # 同上 } }
8 日志切割
-
安装
logrotate
工具,用于日志切割和轮换。在终端中输入以下命令进行安装:
sudo yum install logrotate -y
-
创建一个新的配置文件,例如
/etc/logrotate.d/nginx
,并编辑该文件。在文件中添加以下内容:
/var/log/nginx/*.log { daily missingok rotate 7 compress delaycompress notifempty create 0640 www-data adm sharedscripts postrotate if [ -f /var/run/nginx.pid ]; then kill -USR1 `cat /var/run/nginx.pid` fi endscript }
这个配置文件定义了如何切割和轮换Nginx的日志文件。具体解释如下:
-
/var/log/nginx/*.log
:指定要切割的日志文件路径,这里以/var/log/nginx/
目录下的所有.log
文件为例。 -
daily
:表示按天切割日志文件。 -
missingok
:如果日志文件不存在,不报错。 -
rotate 7
:保留最近7天的日志文件。 -
compress
:压缩切割后的日志文件。 -
delaycompress
:延迟压缩,即在下一次写入日志时再压缩。 -
notifempty
:如果日志文件为空,不进行切割。 -
create 0640 www-data adm
:创建新的日志文件,权限为0640
,属主为www-data
,属组为adm
。 -
sharedscripts
:共享脚本,避免重复执行。 -
postrotate
:在日志文件切割后执行的命令。这里通过发送USR1
信号给Nginx进程,使其重新打开日志文件。 -
endscript
:结束postrotate
块。
-
保存配置文件并退出。
-
重启Nginx服务以应用新的配置。在终端中输入以下命令:
cd /usr/local/nginx/sbin/ ./nginx -s reload
现在,Nginx的日志文件将按照每天进行切割,并保留最近7天的日志文件。
9 nginx配置静态服务器
9.1 案例
要配置Nginx作为静态服务器,需要编辑Nginx的配置文件。以下是一个简单的示例:
-
打开Nginx配置文件,一般位于
/etc/nginx/nginx.conf
或/etc/nginx/sites-available/default
,取决于你的系统和Nginx安装方式。 -
在
server
块中添加以下代码:
location /static { //别名 通过别名对url中的path进行映射 隐藏静态资源路径 alias /path/to/your/static/files/; }
其中/static/
是你的URL路径前缀,/path/to/your/static/files/
是静态文件的实际路径。
-
保存并关闭文件。
-
重启Nginx服务以应用更改。在终端中输入以下命令:
/usr/local/nginx/sbin/nginx -s reload
现在,你可以通过访问http://yourdomain.com/static/file.jpg
来访问你的静态文件了。
9.2 location匹配规则
-
精确匹配:假设我们有以下配置:
location = /images/ { alias /var/www/html/images/; }
在这个例子中,只有当请求的URI是/images/
时,才会触发这个location块。例如,如果用户访问http://yourdomain.com/images/test.jpg
,Nginx会将请求转发到/var/www/html/images/test.jpg
。
-
前缀匹配:假设我们有以下配置:
location ^~ /images/ { alias /var/www/html/images/; }
在这个例子中,只有当请求的URI以/images/
开头时,才会触发这个location块。例如,如果用户访问http://yourdomain.com/images/test.jpg
或http://yourdomain.com/image/test.jpg
,Nginx都会将请求转发到/var/www/html/images/test.jpg
。注意,由于使用了前缀匹配,所以http://yourdomain.com/image/test.jpg
不会被匹配到。
-
正则匹配:假设我们有以下配置:
location ~ \.(jpg|jpeg|png)$ { alias /var/www/html/images/; }
在这个例子中,只有当请求的URI以.jpg
、.jpeg
或.png
结尾时,才会触发这个location块。例如,如果用户访问http://yourdomain.com/images/test.jpg
或http://yourdomain.com/images/test.jpeg
,Nginx都会将请求转发到/var/www/html/images/test.jpg
。
-
别名匹配:假设我们有以下配置:
location @images { alias /var/www/html/images/; } location = /images/ { alias @images; }
在这个例子中,我们首先定义了一个名为@images
的别名,然后在location = /images/
中使用了这个别名。这样,无论请求的URI是什么,只要它以/images/
开头,就会触发这个location块,并将请求转发到/var/www/html/images/
。