Nginx01---简单使用

基于腾讯云--ubuntu系统

 

1.安装nginx

sudo apt-get install nginx

2.启动，停止nginx

nginx -c /usr/local/nginx/conf/nginx.conf   // -c 为 nginx 的配置文件(可以不是默认的位置) 要知道启动nginx是需要配置文件的

nginx -s quit   //注意：执行该命令的用户需要和启动的 nginx 的用户一致。否则我们无法关闭nginx。

stop   — 直接关闭 nginx
quit   — 会在处理完当前正在的请求后退出，也叫优雅关闭
reload — 重新加载配置文件，相当于重启
reopen — 重新打开日志文件 比如，等待当前子进程处理完正在执行的请求后，结束 nginx 进程，可以使用下列命令

nginx 的主进程的进程 ID 是写死在 nginx.pid 文件中的。该文件通常放在 /usr/local/nginx/logs 或者 /var/run 目录下。比如，如果主进程的 ID 是 1628，为了发送 QUIT 信号来使 nginx 优雅退出，可以执行：kill -s QUIT 1628

为了得到所有正在运行的 nginx 进程，我们可能会使用到 ps 工具：ps -ax | grep nginx

3.重新加载配置

nginx -s reload //执行该命令的用户需要和启动的 nginx 的用户一致。（否则可能导致reload失败）

一旦主进程接收到重载配置文件的命令后，它会先检查配置文件语法的合法性，如果没有错误，则会重新加载配置文件。如果成功，则主进程会重新创建一个子进程并且发送关闭请求给以前的子进程。如果没有成功，主进程会回滚改动并且继续使用以前的配置。老的子进程在接受关闭的命令后，会停止接受新的请求并且继续处理当前的请求，直到处理完毕。之后，该子进程就直接退出了。

默认配置文件位置：这三个文件都在/etc/nginx下

/etc/nginx/nginx.conf（这个是文件，下面两个 是文件夹）

/etc/nginx/sites-available

/etc/nginx/conf.d

nginx的配置文件的读写顺序问题：nginx的配置文件是/etc/nginx/nginx.conf，这个配置文件中又引用了/etc/nginx/conf.d/和/etc/nginx/sites-enabled/这两个文件夹的配置文件，通过include来实现。所以，无论是直接在nginx.conf或者在conf.d、sites-enabled中配置都是可以的。

注意：nginx.conf中include命令是在http上下文中，这也就说明了在sites-available文件夹和conf.d文件夹下的文件是server块级指令。

这些全部都是默认的读写文件：所以我们可以直接在这些文件夹下进行创建，注意上面的层级关系，或者修改成自己的。默认的配置文件已经包含了一些关于 server 指令的样式，大多数情况下直接把他们给注释掉。

 

4.配置文件的基本结构

# 开头的行，会被当做注释。

nginx 是由一些模块组成，我们一般在配置文件中使用一些具体的指令来控制它们。指令被分为简单指令和块级命令。

简单指令是由名字和参数组成，中间用空格分开，并以分号结尾：
// 简单指令
root /data/www;

块级指令和简单指令一样有着类似的结构，但是末尾不是分号而是用 { 和 } 大括号包裹的额外指令集。

上下文：如果一个块级指令的大括号里有其他指令，则它被叫做一个上下文（比如：events，Module ngx_http_core_module，server，和 location。在配置文件中，没有放在任何上下文中的指令都是处在主上下文中。events 和 http 的指令是放在主上下文中，server 放在 http 中, location 放在 server 中。

# this is a comment

events {
    worker_connections 4096; ## Default: 1024
}

http {
    server { 
        listen 80;
        server_name domain1.com www.domain1.com;
        access_log logs/domain1.access.log main;
        root html;

        location ~ .php$ {
            fastcgi_pass 127.0.0.1:1025;
}
}
}                                

5.搭建nginx静态服务器

location指令：一个重要的网络服务器的任务是处理文件（比如图片或者静态 HTML 文件）。一旦 nginx 决定哪个服务进程处理请求，它会根据在 server 块级指令中定义好location 指令的参数，来匹配请求头中指定的 URI。

root命令：文件会从不同的目录中映射（取决于取决于location后的正正则）。

比如，响应 http://localhost/some/example.html 的请求，nginx 会发送 /data/www/some/example.html 文件。

server指令：该配置文件可能会包含多个 server 指令。这些 server 指令监听不同的端口和服务器名。

默认的配置文件已经包含了一些关于 server 指令的样式，大多数情况下直接把他们给注释掉。现在，注释掉其他的区块，然后写一个新的 server 区块（新的server区块要在http下）：

http {
    server {
　　　　location / {
　　　　　　　　root /data/www;
　　　　　　}
    }
}

该 location 指令相对于请求中的 URI 执行了 “/” 的前缀。为了匹配请求，URI 会被添加到 root 命令指定的路径后，即 /data/www，得到本地文件系统中请求文件的路径。如果，有几个 location 匹配到，那么 nginx 会选择最长的前缀。上面的 location 提供了长度为 1 的前缀，所以，仅当其他的 location 匹配失败后，该指令才会使用。 接着，添加第二个 location 区块：

location /images/ {
    root /data;
}

它会匹配到以 /images/ 开头的请求（location / 也会匹配到该请求 ，只是前缀更短，所以不会匹配 / ） server 块级命令的配置结果如下：

server {
    location / {
        root /data/www;
}

    location /images/ {
        root /data;
}
}

这已经是一个可用的服务器配置，它监听标准的 80 端口并且可以在本地上通过 http://localhost/ 访问。

对于 URI 以 /images/ 开头的请求，服务器会从 /data/images 目录中，返回对应的文件。例如，nginx 会返回 /data/images/example.png 文件，当接收http://localhost/images/example.png 的请求响应时。如果该文件不存在，nginx 会返回一个 404 错误的响应。没有以 /images/ 开头的 URI 的请求，将会直接映射到 /data/www 目录中。

修改location指令集，使他返回一些典型后缀的图片文件请求，现在它只会映射带有 /images/ 前缀的请求到 /data/images 目录下。修改后的 location 指令如下：

location ~ .(gif|jpg|png)$ {
    root /data/images;
}

该参数是一个正则表达式，它会匹配所有以 .gif，.jpg 或者 .png 结尾的 URIs。一个正则表达式需要以 ~ 开头。匹配到的请求会被映射到 /data/images 目录下。 当 nginx 在选择 location 去响应一个请求时，它会先检测带有前缀的 location 指令，记住先是检测带有最长前缀的 location，然后检测正则表达式。如果有一个正则的匹配的规则，nginx 会选择该 location，否则，会选择之前缓存的规则。 

语法规则： location [=|~|~*|^~] /uri/ { … }
= 开头表示精确匹配

^~ 开头表示uri以某个常规字符串开头，理解为匹配 url路径即可。nginx不对url做编码，因此请求为/static/20%/aa，可以被规则^~ /static/ /aa匹配到（注意是空格）。

~ 开头表示区分大小写的正则匹配

~*  开头表示不区分大小写的正则匹配

!~和!~*分别为区分大小写不匹配及不区分大小写不匹配 的正则

/ 通用匹配，任何请求都会匹配到。

多个location配置的情况下匹配顺序为（参考资料而来，还未实际验证，试试就知道了，不必拘泥，仅供参考）：

首先匹配 =，其次匹配^~, 其次是按文件中顺序的正则匹配，最后是交给 / 通用匹配。当有匹配成功时候，停止匹配，按当前匹配规则处理请求。

例子，有如下匹配规则：

1

location = / {精确匹配，必须是127.0.0.1/

#规则A

}

location = /login {精确匹配，必须是127.0.0.1/login

#规则B

}

location ^~ /static/ {非精确匹配，并且不区分大小写，比如127.0.0.1/static/js.

#规则C

}

location ~ .(gif|jpg|png|js|css)$ {区分大小写，以gif,jpg,js结尾

#规则D

}

location ~* .png$ {不区分大小写，匹配.png结尾的

#规则E

}

location !~ .xhtml$ {区分大小写，匹配不已.xhtml结尾的

#规则F

}

location !~* .xhtml$ {

#规则G

}

location / {什么都可以

#规则H

}

那么产生的效果如下：

访问根目录/， 比如http://localhost/ 将匹配规则A

访问 http://localhost/login 将匹配规则B，http://localhost/register 则匹配规则H

访问 http://localhost/static/a.html 将匹配规则C

访问 http://localhost/a.gif, http://localhost/b.jpg 将匹配规则D和规则E，但是规则D顺序优先，规则E不起作用， 而 http://localhost/static/c.png 则优先匹配到 规则C

访问 http://localhost/a.PNG 则匹配规则E， 而不会匹配规则D，因为规则E不区分大小写。

访问 http://localhost/a.xhtml 不会匹配规则F和规则G，http://localhost/a.XHTML不会匹配规则G，因为不区分大小写。规则F，规则G属于排除法，符合匹配规则但是不会匹配到，所以想想看实际应用中哪里会用到。

访问 http://localhost/category/id/1111 则最终匹配到规则H，因为以上规则都不匹配，这个时候应该是nginx转发请求给后端应用服务器，比如FastCGI（php），tomcat（jsp），nginx作为方向代理服务器存在。

所以实际使用中，个人觉得至少有三个匹配规则定义，如下：
#这里是直接转发给后端应用服务器了，也可以是一个静态首页

# 第一个必选规则

location = / {

proxy_pass http://tomcat:8080/index

}

# 第二个必选规则是处理静态文件请求，这是nginx作为http服务器的强项

# 有两种配置模式，目录匹配或后缀匹配,任选其一或搭配使用

location ^~ /static/ {

root /webroot/static/;

}

location ~* .(gif|jpg|jpeg|png|css|js|ico)$ {

root /webroot/res/;

}

#第三个规则就是通用规则，用来转发动态请求到后端应用服务器

#非静态文件请求就默认是动态请求，自己根据实际把握

#毕竟目前的一些框架的流行，带.php,.jsp后缀的情况很少了

location / {

proxy_pass http://tomcat:8080/

}

#直接匹配网站根，通过域名访问网站首页比较频繁，使用这个会加速处理，官网如是说。

#这里是直接转发给后端应用服务器了，也可以是一个静态首页

# 第一个必选规则

location = / {

proxy_pass http://tomcat:8080/index

}

# 第二个必选规则是处理静态文件请求，这是nginx作为http服务器的强项

# 有两种配置模式，目录匹配或后缀匹配,任选其一或搭配使用

location ^~ /static/ {

root /webroot/static/;

}

location ~* .(gif|jpg|jpeg|png|css|js|ico)$ {

root /webroot/res/;

}

#第三个规则就是通用规则，用来转发动态请求到后端应用服务器

#非静态文件请求就默认是动态请求，自己根据实际把握

#毕竟目前的一些框架的流行，带.php,.jsp后缀的情况很少了

location / {

proxy_pass http://tomcat:8080/

}

为了使用新的配置文件，如果还没开启 nginx 需要先开启，然后将重载信号发送给 nginx 的主进程，通过执行：

nginx -s reload

如果你发现有些地方出了问题，你可以在 /usr/local/nginx/logs 或者 /var/log/nginx 目录下的 access.log 和 error.log 文件中，找到原因。（如果你的server没有配置默认的access，和error目录，如果你配置了，那就去该去的地方找）

server {
    listen 80; 
    server_name 140.143.62.230; 
    access_log /home/ubuntu/Logo_website/logs/access.log; 
    error_log /home/ubuntu/Logo_website/logs/error.log;

location / {

    include uwsgi_params;
    uwsgi_pass 127.0.0.1:5052; 
    uwsgi_param UWSGI_CHDIR /home/ubuntu/Logo_website;
    uwsgi_param UWSGI_SCRIPT Logo_website:app; 
}
location /image/ {

    alias
    /home/ubuntu/Logo_website/uploads_flask/;
}
}

6.配置nginx作为代理服务器

所谓反向代理，很简单，其实就是在location这一段配置中的root替换成proxy_pass即可。

root说明是静态资源，可以由Nginx进行返回；而proxy_pass说明是动态请求，需要进行转发，比如代理到Tomcat上。

nignx有一个主进程，和n个子进程
主：加载和执行配置文件，并且驻留子进程
子：实际的请求处理

当server中的监听端口没有定义时，就是监听默认的80端口，

server {
    location / {
        proxy_pass http://localhost:8080;
    }

    location /images/ {
        root /data;
    }
}

server {    
　　listen 8080;    
　　root /data/up1;    
　　location / {     
　　} 
}

上面就是一个简单的服务器，它监听在 8080 端口（之前，listen 并没被定义，是因为默认监听的 80 端口）并且会映射所有的请求给 本地文件目录 /data/up1。创建该目录，然后添加 index.html 文件。
注意，root 指令是放在 server 上下文中。当响应请求的 location区块中，没有自己的 root 指令，上述的 root 指令才会被使用。

 7.配置服务器名称

服务器名称是用server_name指令来定义的，并且它决定了哪一个server块将用来处理给定的请求。可以使用精确名称、通配符、正则表达式来定义服务器名称。

8.端口号

服务器和客户端都有端口号，但是，服务器的端口号是重要的，因为客户端只有了解了服务器的地址和端口号，才可以连接到它（即使是采用UDP传输数据，也需要指定发送目标的地址和端口号）；而客户端的端口号是无关紧要的，一般由操作系统自动分配。

本地端口是你主机上可以接的接口,简单地说,本地端口就是本地可以对外提供服务或与外界连接的接口。

服务器所有应用通信都是通过对应的端口建立的，端口范围是1-65535，window服务器默认远程管理服务端口是3389，为了增强安全性，一般都会更改3389端口。修改默认远程服务3389端口后（您也可以联系景安客服人员，让售后技术帮您进行修改），登录服务器时在ip地址后面输入”:端口号”就可以了。

服务端怎么知道和客户端的哪个进程连接???
---------------------------------------------------------
对于TCP，服务器在客户端连接后，会在监听套接字之外另外生成一个新的套接字，表示与客户端的连接，这个套接字了解客户端的地址和端口号，从而可以区分是哪个客户端；
对于UDP，服务器在收到UDP数据时，也了解数据来自什么地址和端口，也可以区分是哪个客户端。

从基本的网络概念来说，网络层(IP)负责两个主机间的通信，用IP地址区分主机；传输层(TCP和UDP)处理两个进程间(可以是在同一台机器中的两个进程，也可以是不同主机中的两个进程）的通信，用端口号区分进程。两者合起来就是，用 IP地址+传输层协议+端口号 来区分与谁进行通信。(传输层协议就是指TCP或者UDP，也可以是别的传输层协议，因为互联网协议栈是个开放的结构，其他传输层协议也可以利用IP作为网络层提供的服务）

不论是服务器编程还是客户端编程，其中设置的主机（ip地址），端口号都是服务器端的ip和端口号。客户端的端口号由系统自动分配。客户端端口号和服务器端的端口号没必要相同。服务器要监听客户机的链接，所以需要人为的设置绑定端口。这样客户端才能根据ip地址和端口号访问服务器。服务器端的accept（）函数接收到客户端连接时，便重新建立一个socket，这个socket里面含有客户端的地址和端口号信息，以此实现服务器和客户端的通信。 侦听端口是服务器向客户端所开放的端口，也就是客户端要连接服务器需要的目标端口。通信端口是客户端去访问服务器端口时所携带的源端口，这两个端口号是不一样的，服务端侦听的端口号一般是固定的，而客户端的通信源端口号是随机产生的。

如果想自己指定客户端的端口，那么可以向在服务端一样，在socket（）创建客户端套接字后，调用一下bind（）函数来绑定本机端口。然后在调用connect（）函数绑定服务器的主机和端口。

9.配置 HTTPS 服务器

修改 conf/nginx.conf 文件，必须在配置文件 server 块中的监听指令 listen 后启用 ssl 参数，并且指定服务器证书 ssl_certificate 和私钥 ssl_certificate_key 的位置：

server {
listen 443 ssl;
server_name www.example.com;
ssl_certificate www.example.com.crt;
ssl_certificate_key www.example.com.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;
...
}
服务器证书是一个公共实体，它被发送给连接到服务器的每一个客户机。私钥是一个安全实体，应该存储在具有受限访问的文件中，但它必须可被nginx主进程读取。私钥也可以存储在与服务器证书相同的文件中：

ssl_certificate www.example.com.cert;
ssl_certificate_key www.example.com.cert;
在这种情况下，这个证书文件的访问权限也应受到限制。虽然证书和密钥存储在一个文件中，但只有证书被发送到客户端。

指令 ssl_protocols 和 ssl_ciphers 可用于限制仅包括强版本和密码的 SSL/TLS 连接。 默认情况下，NGINX 使 用ssl_protocols TLSv1 TLSv1.1 TLSv1.2版本和ssl_ciphers HIGH:!aNULL:!MD5密码，因此通常不需要显式地配置它们。需要注意的是，这些指令的默认值在不同的版本里面已经变更好几次了。

10.负载均衡

负载均衡【upstream】

上面的反向代理中，我们通过proxy_pass来指定Tomcat的地址，很显然我们只能指定一台Tomcat地址，那么我们如果想指定多台来达到负载均衡呢？

第一，通过upstream来定义一组Tomcat，并指定负载策略（IPHASH、加权论调、最少连接），健康检查策略（Nginx可以监控这一组Tomcat的状态）等。

第二，将proxy_pass替换成upstream指定的值即可。

负载均衡可能带来的问题？

负载均衡所带来的明显的问题是，一个请求，可以到A server，也可以到B server，这完全不受我们的控制，当然这也不是什么问题，只是我们得注意的是：用户状态的保存问题，如Session会话信息，不能在保存到服务器上。

缓存

缓存，是Nginx提供的，可以加快访问速度的机制，说白了，在配置上就是一个开启，同时指定目录，让缓存可以存储到磁盘上。具体配置，大家可以参考Nginx官方文档，这里就不在展开了。

 

 

 

 

 

11.虚拟主机

在同一个服务器上部署多个网站。

有的网站访问量大，需要负载均衡。然而并不是所有网站都如此出色，有的网站，由于访问量太小，需要节省成本，将多个网站部署在同一台服务器上。例如将www.aaa.com和www.bbb.com两个网站部署在同一台服务器上，两个域名解析到同一个IP地址，但是用户通过两个域名却可以打开两个完全不同的网站，互相不影响，就像访问两个服务器一样，所以叫两个虚拟主机。配置：

server {
    listen 80 default_server;
    server_name _;
    return 444; # 过滤其他域名的请求，返回444状态码
}
server {
    listen 80;
    server_name www.aaa.com; # www.aaa.com域名
    location / {
        proxy_pass http://localhost:8080; # 对应端口号8080
    }
}
server {
    listen 80;
    server_name www.bbb.com; # www.bbb.com域名
    location / {
        proxy_pass http://localhost:8081; # 对应端口号8081
    }
}

在服务器8080和8081分别开了一个应用，客户端通过不同的域名访问，根据server_name可以反向代理到对应的应用服务器。虚拟主机的原理是通过HTTP请求头中的Host是否匹配server_name来实现的，有兴趣的同学可以研究一下HTTP协议。另外，server_name配置还可以过滤有人恶意将某些域名指向你的主机服务器。

第一：location可以进行正则匹配，应该注意正则的几种形式以及优先级。（这里不展开）

第二：Nginx能够提高速度的其中一个特性就是：动静分离，就是把静态资源放到Nginx上，由Nginx管理，动态请求转发给后端。

第三：我们可以在Nginx下把静态资源、日志文件归属到不同域名下（也即是目录），这样方便管理维护。

第四：Nginx可以进行IP访问控制，有些电商平台，就可以在Nginx这一层，做一下处理，内置一个黑名单模块，那么就不必等请求通过Nginx达到后端在进行拦截，而是直接在Nginx这一层就处理掉。 

 

 

12.软链加载配置

删掉 Nginx 的默认配置文件，在/etc/nginx/conf.d/中创建配置，实际上是创建软链

直接在当前目录下创建配置文件，将 Nginx 配置文件用软链接链接到 Nginx 配置文件夹中：

$ sudo rm /etc/nginx/sites-enabled/default

sudo ln -s /home/frank/Documents/helloflask/helloflask_nginx.conf /etc/nginx/conf.d/

相当于快捷方式：  ln -s [源文件或目录] [目标文件或目录]  为某一个文件在另外一个位置建立一个同不的链接

一般用法就是在目标文件夹下创建其他文件或者文件夹的链接。注意目标文件夹分为相对路径和绝对路径  当面/开头就是相对路径       lll/ddd  就是在当前目录下创建  lll文件夹   之后创建ddd文件夹  最后在其中放置  链接的文件夹和文件   颜色一般为天蓝色。    lll/ddd 等于  ./lll/ddd

创建软链接，当我们需要在不同的目录，用到相同的文件时，我们不需要在每一个需要的目录下都放一个必须相同的文件，我们只要在某个固定的目录，放上该文件，然后在其它的 目录下用ln命令链接（link）它就可以，不必重复的占用磁盘空间。例如：ln -s /bin/less /usr/local/bin/less -s 是代号（symbolic）的意思。这 里有两点要注意：第一，ln命令会保持每一处链接文件的同步性，也就是说，不论你改动了哪一处，其它的文件都会发生相同的变化；第二，ln的链接又软链接 和硬链接两种，软链接就是ln -s ** **,它只会在你选定的位置上生成一个文件的镜像，不会占用磁盘空间，硬链接ln ** **,没有参数-s, 它会在你选定的位置上生成一个和源文件大小相同的文件，无论是软链接还是硬链接，文件都保持同步变化。

例如：

当前路径创建test 引向/var/www/test 文件夹

ln –s /var/www/test test

创建/var/test 引向/var/www/test 文件夹

ln –s /var/www/test /var/test

在目标文件夹，建立链接，即源文件链接，后面这个是我们创建的，删除的时候也是删除它

ln -s /home/frank/Documents/helloflask/helloflask_nginx.conf  /etc/nginx/conf.d/

删除软链接和删除普通的文件是一眼的，删除都是使用rm来进行操作

rm –rf 软链接名称（请注意不要在后面加”/”，rm –rf 后面加不加”/” 的区别，可自行去百度下啊）

rm –rf test      //删除test 

13.配置文件范文

server {

# 这个server标识我要配置了


listen 80; # 我要监听那个端口


server_name 10.129.205.183 ; # 你访问的路径前面的url名称


access_log /var/log/nginx/access.log main; # Nginx日志配置


charset utf-8; # Nginx编码


gzip on; # 启用压缩,这个的作用就是给用户一个网页,比如3M压缩后1M这样传输速度就会提高很多


gzip_types text/plain application/x-javascript text/css text/javascript application/x-httpd-php application/json text/json image/jpeg image/gif image/png application/octet-stream; # 支持压缩的类型

error_page 404 /404.html; # 错误页面


error_page 500 502 503 504 /50x.html; # 错误页面

 

# 指定项目路径uwsgi
location / { # 这个location就和咱们Django的url(r'^admin/', admin.site.urls),
　　include uwsgi_params; # 导入一个Nginx模块他是用来和uWSGI进行通讯的
　　uwsgi_connect_timeout 30; # 设置连接uWSGI超时时间
　　uwsgi_pass unix:/opt/project_teacher/script/uwsgi.sock; # 指定uwsgi的sock文件所有动态请求就会直接丢给他
}

 

# 指定静态文件路径
location /static/ {
　　alias /opt/project_teacher/teacher/static/;
　　index index.html index.html;
}