Nginx配置详解

泥泞的我

已于 2023-03-11 15:31:49 修改

阅读量263

点赞数

分类专栏： nginx 文章标签： nginx 服务器运维

于 2023-03-05 15:02:57 首次发布

本文链接：https://blog.csdn.net/q535175584/article/details/129346157

版权

nginx 专栏收录该内容

1 篇文章

订阅专栏

文章详细介绍了Nginx中的location匹配规则，包括精准匹配、大小写敏感/忽略、uri开头匹配以及命名匹配等，并阐述了location的匹配流程和优先级。同时，文章讲解了upstream模块的负载均衡配置，如常用参数、负载均衡算法（轮询、最少连接、IPHash）以及如何处理服务器故障。

摘要由CSDN通过智能技术生成

1.基本结构

// nginx全局块
...

// events块
events {
...
}

// http 块
http {
// http全局块
...

// server块
server {
...
}

// http全局块
...
}
// upstream 块
upstream {

}

2.location匹配规则详解

语法规则：


# = 开头表示精准匹配
# ~ 大小写敏感
# ~* 忽略大小写
# ^~ 只需匹配uri开头
# @ 定义一个命名的 location，在内部定向时使用，例如 error_page
location  [ = | ~ | ~* | ^~ ] /uri/ { ... }
location @name { ... }

1、任意匹配


# 匹配所有请求，但是正则和最长字符串会优先匹配
location / {
    #规则
}

2、“=” 精准匹配


# 精确匹配 / ，可以匹配类似 `http://www.example.com/` 这种请求，'/'后不能带有任何内容
location = / {
   #规则
}

3、“~” 大小写敏感


location ~ /Test/ {
    #规则
}
#可以匹配    http://www.test.com/Test/
#不可以匹配    http://www.test.com/test/

4、 “~*” 大小写忽略


# ~* 会忽略uri部分的大小写
location ~* /Test/ {
    #规则
} 
#可以匹配    http://www.test.com/test/

5、 “^~” 只匹配uri开头


#以 /test/ 开头的请求，都可以匹配上
location ^~ /test/ {    #规则
}
#可以匹配    http://www.test.com/test/

6、“@” 命名匹配


#以 /img/ 开头的请求，如果链接的状态为 404。则会匹配到 @img_err 这条规则上。
location /img/ {
    error_page 404 @img_err;
}
location @img_err {
    # 规则
}

7、以内容结尾匹配

1
2
3
4
# 匹配所有以 gif,jpg或jpeg 结尾的请求
location ~* \.(gif|jpg|jpeg)$ {
  #规则
}

8、location匹配优先级

在配置中需要注意的一点就是location的匹配规则和优先级

= 开头表示精确匹配
^~ 开头表示uri以某个常规字符串开头，不是正则匹配;
~ 开头表示区分大小写的正则匹配;
~* 开头表示不区分大小写的正则匹配;
/ 通用匹配, 如果没有其它匹配,任何请求都会匹配到;

9、location的匹配流程

A、判断是否精准匹配，如果匹配，直接返回结果并结束搜索匹配过程。
B、判断是否普通匹配，如果匹配，看是否包含^~前缀，包含则返回，否则记录匹配结果，(如果匹配到多个location时返回或记录最长匹配的那个)
C、判断是否正则匹配，按配置文件里的正则表达式的顺序，由上到下开始匹配，一旦匹配成功，直接返回结果，并结束搜索匹配过程。
D、如果正则匹配没有匹配到结果，则返回步骤B记录的匹配结果。

注意：

A、多个普通匹配的location时，和location的顺序无关，总是匹配所有的location，然后取匹配最长的location作为结果

B、多个正则匹配的location时，和顺序有关，从上到下依次匹配，一旦匹配成功便结束，直接返回结果。

3.负载均衡

upstream是Nginx的HTTP Upstream模块，这个模块通过一个简单的调度算法来实现客户端IP到后端服务器的负载均衡

1、Upstream常用参数介绍

语法：server address [parameters]

其中关键字server必选。
address也必选，可以是主机名、域名、ip或unix socket，也可以指定端口号。
parameters是可选参数，可以是如下参数：

down：表示当前server已停用

backup：表示当前server是备用服务器，只有其它非backup后端服务器都挂掉了或者很忙才会分配到请求

weight：表示当前server负载权重，权重越大被请求几率越大。默认是1

max_fails和**fail_timeout**一般会关联使用，如果某台server在fail_timeout时间内出现了max_fails次连接失败，那么Nginx会认为其已经挂掉了，从而在fail_timeout时间内不再去请求它，fail_timeout默认是10s，max_fails默认是1，即默认情况是只要发生错误就认为服务器挂掉了，如果将max_fails设置为0，则表示取消这项检查。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
upstream tomcatcluster { ## 方向代理名称不能有下划线
	server 192.168.3.199:6666 weight=1;
    server 192.168.3.199:7777 weight=1;
	server 192.168.3.199:8888 weight=1;
}

server {
	listen 80;
	server_name www.zhaoxi.com;
	
	location / {
		proxy_pass http://tomcat_cluster;
	}
}

在做负载均衡前，我们首先需要定义一个 Server 组用来表示所有存在的后台服务：

1
2
3
4
5
6
7
http {
    upstream backend {
        server backend1.example.com weight=5;
        server backend2.example.com;
        server 192.0.0.1 backup;
    }
}

然后，我们需要把流量重定向到上一步定义的 backend 上去, 我们可以通过指定 proxy_pass 的值来完成这一操作：

1
2
3
4
5
6
7
8
9
10
11
12
    upstream backend {
        server backend1.example.com;
        server backend2.example.com;
        server 192.0.0.1 backup;
    }
    
    server {
        location / {
            proxy_pass http://backend;
        }
    }
}

这里我们将所有的流量重定向到 http://backend , 这将这个 NGINX 实例上的所有流量重定向到之前定义的 backend 上去。

负载均衡算法

当没有指定任何信息时， NGINX 默认使用了 Round Robin(轮询)算法来重定向流量。其实 NGINX 提供了多种算法来做负载均衡，下面我们来介绍一下：

1、Round Robin (轮询)

在没有指定 weight(权重) 的情况下，Round Robin 会将所有请求均匀地分发给所有后台服务实例：

1
2
3
4
upstream backend {
    server backend1.example.com;
    server backend2.example.com;
}

这里我们没有指定权重，所以两个后台服务会收到等量的请求。但是，当指定了权重之后，NGINX 就会将权重考虑在内：

1
2
3
4
upstream backend {
    server backend1.example.com weight=5;
    server backend2.example.com;
}

在 NGINX 中，weight 默认被设置为 1。这里我们用一开始的配置举例， backend1.example.com 的权重被设置为 5，另一个的权重没设置，所以是默认值 1。我们也没有设置轮询算法，所以这时候 NGINX 会以 5：1 的比例转发请求，即 6 个请求中， 5 个被放到了 backend1.example.com 上，有一个被发到了 backend2.example.com 上。

2、Least Connections（最少连接算法）

在这个模式下，一个请求会被 NGINX 转发到当前活跃请求数量最少的服务实例上：

1
2
3
4
5
upstream backend {
    least_conn;
    server backend1.example.com;
    server backend2.example.com;
}

我们用 least_conn 来指定最少连接优先算法, NGINX 会优先转发请求到现有连接数少的那一个服务实例上。

3、IP Hash (IP 哈希)

在 IP Hash 模式下，NGINX 会根据发送请求的 IP 地址的 hash 值来决定将这个请求转发给哪个后端服务实例。被 hash 的 IP 地址要么是 IPv4 地址的前三个 16 进制数或者是整个 IPv6 地址。使用这个模式的负载均衡模式可以保证来自同一个 IP 的请求被转发到同一个服务实例上。当然，这种方法在某一个后端实例发生故障时候会导致一些节点的访问出现问题。

1
2
3
4
5
upstream backend {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
}

如果某一台服务器出现故障或者无法进行服务，我们可以给它标记上 down，这样之前被转发到这台服务器上的请求就会重新进行 hash 计算并转发到新的服务实例上:

1
2
3
4
5
upstream backend {
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com down;
}

NGINX 提供了多种负载均衡模式，在实际使用中，需要根据实际业务需求去做尝试，分析日志来找到最适合当前场景的复杂均衡模式。