Nginx 反向代理和正向代理

---

🌐 Nginx 代理模式

Nginx 可以以正向代理和反向代理两种模式工作。这两种模式都涉及客户端、代理服务器和目标服务器，但它们的工作方式和目的都有所不同。

---

🔄 反向代理 (Reverse Proxy)

🎯 作用：

1. 📊 负载均衡：在多个后端服务器之间分发客户端请求，以确保没有任何服务器过载。
2. 🚀 Web 加速：使用缓存来减少后端服务器的负载并加快响应速度。
3. 🔐 SSL 终止：处理 SSL/TLS 握手和解密，释放后端服务器的负担。
4. 🛡️ 安全和匿名性：隐藏后端服务器的真实 IP 地址和身份，为后端服务器提供一个保护层，从而提高安全性。

🔄 工作流程：

• 客户端发起请求到代理服务器。
• 代理服务器根据某种策略决定将请求转发到哪个后端服务器。
• 后端服务器处理请求并返回响应给代理服务器。
• 代理服务器再将响应返回给客户端。

---

🚀 正向代理 (Forward Proxy)

🎯 作用：

1. 🚫 访问限制：企业或学校可能使用正向代理来限制员工或学生访问特定的外部网站。
2. 🔍 内容过滤：正向代理可以用来过滤某些不安全或不恰当的内容。
3. 🚀 缓存：减少外部请求并加速访问速度。
4. 🕵️ 匿名浏览：隐藏用户的真实 IP 地址，使用户可以匿名访问互联网。

🔄 工作流程：

• 客户端发起请求到代理服务器。
• 代理服务器将请求转发到目标服务器。
• 目标服务器处理请求并返回响应给代理服务器。
• 代理服务器再将响应返回给客户端。

---

📌 主要区别

属性/代理类型	🔄 反向代理	🚀 正向代理
🎯 目的	通常在服务器端，用于负载均衡、安全、加速等。	通常在客户端，用于匿名浏览、访问控制、内容过滤等。
📍 位置	位于后端服务器和客户端之间。	位于客户端和所有互联网服务器之间。
🧠 知晓性	客户端可能不知道自己正在与反向代理通信。	客户端通常知道并显式配置其浏览器或应用程序以使用正向代理。
🔧 配置	通常由网站或应用程序的管理员配置。	通常由终端用户或其网络管理员配置。

🔹 相似性：

1. 代理行为：无论是正向代理还是反向代理，它们都接收客户端的请求，然后将这些请求转发到其他地方，并将结果返回给客户端。
2. 配置方式：在 Nginx 中，两者的配置结构都使用 location 和 proxy_pass 指令。这意味着，从结构上看，它们在配置文件中看起来非常相似。

🔹 差异性：

1. 目标：

   • 正向代理：代理的目标是代表客户端与互联网上的服务器交互。通常用于内容过滤、安全性、匿名浏览等。
   • 反向代理：代理的目标是代表后端服务器与客户端交互。常用于负载均衡、SSL 终止、缓存等。

2. 知晓性：

   • 正向代理：客户端知道并配置自己去使用代理。
   • 反向代理：客户端通常不知道自己正在与反向代理通信，而认为自己直接与后端服务器通信。

3. 配置上的差异：

   • 正向代理：可能需要配置访问控制、内容过滤规则和缓存策略。
   • 反向代理：可能需要配置负载均衡策略、健康检查、SSL 终止等。

---

🤖 代理请求

当 NGINX 服务器代理请求时，它将请求发送到指定的服务器，获取响应，并将其发送回客户端。可以使用指定的协议向 HTTP 服务器或非HTTP 服务器发送代理请求。支持的协议包括 FastCGI、uwsgi、SCGI 和 Memcached。

要将请求传递到 HTTP 代理服务器，使用 proxy_pass 指令。例如：

📌 HTTP 代理:

location /some/path/ {
    proxy_pass http://www.example.com/link/;
}

📌 其他代理:

• FastCGI: 使用 fastcgi_pass 指令将请求转发到 FastCGI 服务器。
• uwsgi: 使用 uwsgi_pass 指令将请求转发到 uwsgi 服务器。
• SCGI: 使用 scgi_pass 指令将请求转发到 SCGI 服务器。
• Memcached: 使用 memcached_pass 指令将请求转发到 memcached 服务器。

---

🧲 反向代理 (Reverse Proxy) 服务端

---

1️⃣ 负载均衡 :

当你的网站流量增加时，一个服务器可能不足以处理所有请求。在这种情况下，你可以设置多个应用服务器，并使用 Nginx作为负载均衡器，根据特定的算法（如轮询、最少连接等）将请求分发到各个服务器。

算法	对故障服务器的处理	服务器恢复后的行为
轮询（Round Robin）	继续发送请求到故障服务器，可能导致失败或超时	恢复后重新开始分发请求
权重（Weighted RR）	停止发送请求到故障服务器，直到恢复正常	恢复后重新开始分发请求，根据权重可能有不同的比例
最小连接（Least Conn）	继续发送请求到故障服务器，可能导致失败或超时	恢复后重新开始分发请求，基于当前连接数选择服务器
IP哈希（IP Hash）	继续将请求发送到故障服务器	恢复后继续将来自相同IP地址的请求发送到相同服务器

---

📌 热备 (Hot Standby)

当您有一个备份服务器可用时，您可以配置 Nginx 以只在主服务器失败时使用它。

http {
	upstream myapp0 {
	    server www.example.com;
	    server bad.example.com down;
	    server bak.example.com backup;
	}
	server {
	        listen 80; # 侦听 80 端口
	        server_name www.example.com; # 服务器域名
	
	        location / {
	            proxy_pass http://myapp0; # 转发请求到上面定义的 upstream
	        }
	}
}

📝 注释: 在这里，只有当 myapp01.example.com 失败时，myapp02.example.com 才会开始接收请求。

1. 初始请求:
当一个请求到达 Nginx 并被定向至 myapp0 后端组，首先会尝试转发请求至 www.example.com。这是因为它是 upstream 配置块中的第一个 server 指令。

2. 跳过标记为 down 的服务器:
Nginx 会跳过 bad.example.com，因为它后面的 down 指令标记这个服务器为不可用。

3. 使用备份服务器:
如果 www.example.com 无法处理请求（例如，它宕机或超时），Nginx 会考虑转发请求至 bak.example.com。这是由于它后面的 backup 指令，它被指定为备份服务器，只在其他非备份服务器不可用时才会被考虑。

总结:
默认地，请求会被转发至 www.example.com。只有当 www.example.com 无法处理请求时，才会考虑备份服务器 bak.example.com。而 bad.example.com 由于标记为 down，所以永远不会接收到请求。

---

📌 轮询 (Round Robin)

流程：

1. 客户端发起请求到 Nginx。
2. Nginx 根据轮询策略将请求转发到下一个服务器。
3. 后端服务器处理请求并返回响应到 Nginx。
4. Nginx 将响应返回给客户端。

http {
    upstream myapp1 {
        # 使用轮询算法
        server srv1.example.com; # 第一个服务器
        server srv2.example.com; # 第二个服务器
        server srv3.example.com; # 第三个服务器
    }

    server {
        listen 80; # 侦听 80 端口
        server_name www.example.com; # 服务器域名

        location / {
            proxy_pass http://myapp1; # 转发请求到上面定义的 upstream
        }
    }
}

---

📌 最少连接 (Least Connections)

流程：

1. 客户端发起请求到 Nginx。
2. Nginx 检查所有后端服务器，选择当前有最少活动连接的服务器。
3. 将请求转发到该服务器。
4. 服务器处理请求并返回响应到 Nginx。
5. Nginx 将响应返回给客户端。

http {
    upstream myapp2 {
        least_conn; # 使用最少连接算法
        server srv1.example.com; # 第一个服务器
        server srv2.example.com weight=3; # 第二个服务器，权重为 3
    }
    server {
        listen 80; # 侦听 80 端口
        server_name www.example.com; # 服务器域名

        location / {
            proxy_pass http://myapp2; # 转发请求到上面定义的 upstream
        }
    }
}

---

📌 IP 哈希 (IP Hash)

http {
    upstream myapp3 {
        ip_hash; # 使用 IP 哈希算法
        server srv1.example.com; # 第一个服务器
        server srv2.example.com; # 第二个服务器
    }
    server {
        listen 80; # 侦听 80 端口
        server_name www.example.com; # 服务器域名

        location / {
            proxy_pass http://myapp3; # 转发请求到上面定义的 upstream
        }
    }
}

🌐 IP哈希（IP Hash）负载均衡工作原理：

1. 🚀 客户端发起请求到Nginx。

2. 📡 Nginx获取客户端的IP地址。

3. 🔢 Nginx使用客户端IP地址计算哈希值。这个哈希值通常是一个非负整数。

4. 🎯 哈希值与后端服务器的数量进行取模运算（求余数），以确定应该将请求路由到哪个后端服务器。

   • 🖥️ 假设你有两台后端服务器，分别为 srv1.example.com 和 srv2.example.com。
   • 🧮 如果哈希值是奇数，那么 (哈希值 % 2) 结果为1，请求将路由到 srv2.example.com。
   • 🧮 如果哈希值是偶数，那么 (哈希值 % 2) 结果为0，请求将路由到 srv1.example.com。

5. 🔄 请求被转发到选中的后端服务器，然后由该服务器处理。

• 📝 这个过程确保了相同客户端IP地址的请求将始终被路由到相同的后端服务器，从而维护了会话状态。不同的客户端IP地址将产生不同的哈希值，这会分散负载并确保请求被均匀地分配给后端服务器。

• ⚠️ 需要注意的是，IP哈希算法有一些限制，例如，如果后端服务器的数量变化，哈希值可能导致不均匀的分配。因此，在使用IP哈希算法时，通常需要考虑后端服务器的动态性。如果服务器数量经常变化，可能需要其他负载均衡算法来更好地适应变化。

---

📌 加权负载均衡 (Weighted Load Balancing)

可以为每个后端服务器分配一个权重，权重高的服务器将处理更多的请求。

http {
	upstream myapp4 {
		server myapp41.example.com;
	    server myapp42.example.com weight=3;
	    server myapp43.example.com weight=2;
	}
	server {
        listen 80; # 侦听 80 端口
        server_name www.example.com; # 服务器域名

        location / {
            proxy_pass http://myapp4; # 转发请求到上面定义的 upstream
        }
    }
}

下面是基于你提供的Nginx配置示例的加权负载均衡的运行流程的一个简要说明：

1. 客户端发出请求：客户端向Nginx服务器发送请求。

2. Nginx接收请求：Nginx服务器接收到客户端的请求。

3. 负载均衡器处理请求：请求到达负载均衡器，负载均衡器的任务是决定将请求分发给哪个后端服务器。

4. 权重分配：负载均衡器根据配置中的权重分配决定将请求分发给哪个后端服务器。根据上面的配置示例，如果有10个请求到达负载均衡器，分发可能如下：

   • myapp41.example.com：处理1个请求。
   • myapp42.example.com：处理3个请求。
   • myapp43.example.com：处理2个请求。

5. 请求转发：负载均衡器将请求转发给相应的后端服务器。例如，如果请求被分配给myapp01.example.com，则请求将被发送到myapp01.example.com服务器上。

6. 后端服务器处理请求：被选中的后端服务器接收到请求并处理它，然后生成响应。

7. 响应返回：后端服务器生成的响应被发送回负载均衡器。

8. 负载均衡器返回响应：负载均衡器接收到来自后端服务器的响应，并将其发送回客户端。

9. 客户端接收响应：客户端最终接收到来自Nginx服务器的响应，响应的内容是由后端服务器处理生成的。

---

📌 proxy_next_upstream 指令

当使用 Nginx 进行反向代理和负载均衡时，proxy_next_upstream 指令非常有用。以下是一个完整的 Nginx 示例配置，包括了 proxy_next_upstream 的使用以及一些其他相关配置项的说明：

error 建立连接 / 发送请求 / 接收响应时出错（缺省值之一）；
timeout 建立连接 / 发送请求 / 接收响应时超时（缺省值之一）；
invalid_header 上游返回空白或无效响应；
http_500 上游返回 500 Internal Server Error；
http_501 上游返回 501 Not Implemented；
http_502 上游返回 502 Bad Gateway；
http_503 上游返回 503 Service Unavailable；
http_504 上游返回 504 Gateway Timeout；
http_404 上游返回 404 Not Found；
http_429 上游返回 429 Too Many Requests；
non_idempotent 解除对非幂等请求 (POST, LOCK, PATCH) 的封印，小心造成重复提交；
off 不得转给下一台服务器。

🌐 Nginx配置示例

http {
    upstream myapp5 {
        server myapp51.example.com;
        server myapp52.example.com;
        server myapp53.example.com;
    }

    server {
        listen 80;
        server_name mywebsite.com;

        location / {
            proxy_pass http://myapp5;
            
            # 使用 proxy_next_upstream 指令定义故障转移策略
            proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
            
            # 设置最大失败次数和超时时间
            proxy_max_temp_file_size 0;
            proxy_connect_timeout      5;
            proxy_send_timeout         5;
            proxy_read_timeout         5;
            proxy_buffering            off;
        }
    }
}

解释和说明：

1. 在 upstream 块中定义了一个名为 myapp5 的后端服务器组，其中包含了三个后端服务器。这是要负载均衡的服务器池。

2. 在 server 块中，我们定义了一个虚拟主机，监听端口 80，该虚拟主机用于处理来自 mywebsite.com 的请求。

3. 在 location / 块中，我们配置了反向代理，将请求代理到名为 myapp5 的后端服务器组。这是一个基本的反向代理配置。

4. 🔄 proxy_next_upstream 指令定义了故障转移策略。根据这个配置，当发生以下情况之一时，Nginx 将尝试使用下一个可用的后端服务器：通信错误 (error)、连接或读取超时 (timeout)、后端服务器返回 HTTP 500、502、503 或 504 错误。

5. 我们还设置了一些与代理相关的超时和缓冲参数，以确保在发生问题时有适当的超时和缓冲控制。这些设置可以根据实际需求进行调整。

总之，上述配置演示了如何在 Nginx 中使用 proxy_next_upstream 指令来定义故障转移策略。当一个请求到达时，Nginx 将尝试将其转发到 myapp5 中的服务器，并根据 proxy_next_upstream 指令定义的错误情况来决定是否尝试下一个服务器，从而实现负载均衡和故障转移的目标。

---

2️⃣ Web 加速 :

通过压缩、缓存和连接复用，Nginx 可以加速客户端与服务器之间的数据传输。

---

📌 压缩

流程：

1. 客户端发起请求。
2. Nginx 检查请求头是否支持 gzip。
3. 如果支持，Nginx 从缓存或后端服务器获取未压缩的内容。
4. Nginx 使用 gzip 压缩内容。
5. Nginx 将压缩后的内容返回给客户端。

server {
    gzip on; # 开启 gzip 压缩
    gzip_types text/plain application/xml text/css application/javascript; # 定义哪些 MIME 类型的响应需要被压缩

    location / {
        proxy_pass http://myapp1; # 转发请求到指定的 upstream
    }
}

---

📌 静态内容的缓存

流程：

1. 客户端请求静态内容。
2. Nginx 检查缓存是否有该内容。
3. 如果有，Nginx 直接从缓存返回内容。
4. 如果没有，Nginx 从后端服务器获取内容，存入缓存，并返回给客户端。

location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ { # 对于这些文件类型的请求
    proxy_cache mycache; # 使用名为 "mycache" 的缓存
    proxy_pass http://myapp1; # 转发请求
    proxy_set_header Host $host; # 设置 Host 头
    proxy_cache_valid  365d; # 缓存的有效期为 365 天
}

---

📌 连接复用

流程：

1. 客户端发起多个请求。
2. 使用连接池，Nginx 重用已有的连接到后端服务器，而不是为每个请求建立新连接。
3. 后端服务器处理请求并返回响应到 Nginx。
4. Nginx 将响应返回给客户端。

http {
    upstream myapp0 {
        server myapp01.example.com:8080; # 第一个后端服务器
        server myapp02.example.com:8080; # 第二个后端服务器
        keepalive 32; # 保持连接，最多 32 个
    }

    server {
        location / {
            proxy_pass http://myapp0; # 转发请求
            proxy_set_header Connection ""; # 设置 Connection 头为空
            proxy_http_version 1.1; # 使用 HTTP/1.1 协议
        }
    }
}

---

3️⃣ SSL 终止

---

📌 什么是 SSL 终止？

SSL 终止是一个过程，其中代理服务器（例如 Nginx）负责处理 SSL/TLS 握手和解密客户端的 SSL/TLS 请求，然后将解密的请求传递给后端服务器。这样，后端服务器不需要处理加密和解密的复杂性，从而释放它们的负担。

---

📌 为什么使用 SSL 终止？

1. ⚡ 性能：解密 SSL/TLS 请求是计算密集型的。通过让专门的代理服务器（例如 Nginx）来处理它，可以让后端服务器更专注于业务逻辑处理，从而提高整体性能。
2. 🔄 负载均衡：代理服务器可以在解密请求后，根据内容负载均衡到多个后端服务器。
3. 🔧 简化管理：只需在代理服务器上管理和更新 SSL/TLS 证书，而不是在每个后端服务器上。
4. 🛡️ 安全性：可以在代理服务器上实施更严格的安全策略和升级，而无需修改后端服务器。

---

📌 如何在 Nginx 中设置 SSL 终止？

1. 获取 SSL 证书：首先，你需要为你的域名获得一个 SSL 证书。这可以是自签名的，但为了真正的安全性，最好是从受信任的证书颁发机构获得的。

2. 配置 Nginx：

server {
    listen 443 ssl; # 监听 443 端口并启用 SSL

    server_name yourdomain.com; # 你的域名

    ssl_certificate /etc/nginx/ssl/yourdomain.com.crt; # SSL 证书路径
    ssl_certificate_key /etc/nginx/ssl/yourdomain.com.key; # SSL 私钥路径

    location / {
        proxy_pass http://your_myapp0_server_address; # 后端服务器地址
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

3. 重启 Nginx：sudo service nginx restart

---

📌 流程说明：

1. 客户端向 Nginx 代理服务器发起一个 HTTPS 请求。
2. Nginx 负责处理 SSL/TLS 握手，并使用其私钥解密来自客户端的请求。
3. 解密后的请求（现在是 HTTP）被发送到后端服务器。
4. 后端服务器处理该请求并将响应发送回 Nginx。
5. Nginx 使用客户端的公钥加密响应，并将其作为 HTTPS 响应发送回客户端。
6. 客户端使用其私钥解密 Nginx 的响应。

---

4️⃣ 安全和匿名:

反向代理可以隐藏后端服务器的真实 IP 地址和身份，为后端服务器提供一个保护层，从而提高安全性。

---

📌 隐藏真实的后端服务器 IP

流程：

1. 客户端发起请求。
2. Nginx 作为中间代理转发请求，隐藏后端服务器的真实 IP。
3. 后端服务器处理请求并返回响应到 Nginx。
4. Nginx 将响应返回给客户端，客户端只知道 Nginx 的 IP。

location / {
    proxy_pass http://myapp1; # 转发请求
    proxy_set_header Host $host; # 设置 Host 头
    proxy_hide_header X-Real-IP; # 隐藏 X-Real-IP 头
    proxy_hide_header X-Forwarded-For; # 隐藏 X-Forwarded-For 头
}

---

📌 限制访问

流程：

1. 客户端尝试访问受限的资源。
2. Nginx 检查请求的 IP 地址或其他限制条件。
3. 如果请求被允许，Nginx 将其转发到后端服务器；如果被拒绝，Nginx 返回错误响应。

location /admin/ {
    proxy_pass http://myapp1; # 转发请求
    allow 192.168.1.0/24; # 仅允许这个 IP 范围的访问
    deny all; # 拒绝其他所有请求
}

---

📌 使用 SSL 为代理连接加密

流程：

1. 客户端使用 HTTPS 协议发起请求。
2. Nginx 使用 SSL 证书和私钥解密客户端请求。
3. Nginx 将解密后的请求转发到后端服务器。
4. 后端服务器处理请求并返回响应到 Nginx。
5. Nginx 使用 SSL 加密响应，并将其返回给客户端。

server {
    listen 443 ssl; # 侦听 443 端口，并启用 SSL
    ssl_certificate /etc/nginx/ssl/nginx.crt; # SSL 证书路径
    ssl_certificate_key /etc/nginx/ssl/nginx.key; # SSL 私钥路径

    location / {
        proxy_pass http://myapp1; # 转发请求
        proxy_set_header Host $host; # 设置 Host 头
        proxy_set_header X-Real-IP $remote_addr; # 设置真实的客户端 IP 地址
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # 设置转发的 IP 地址
    }
}

---

🤖 正向代理 (Forward Proxy) 客户端

---

1️⃣ 访问限制：

🚫 示例：阻止访问facebook.com和twitter.com。

server {
    listen 8080;

    location / {
        # 检查请求的Host是否是被禁止的站点
        if ($http_host ~* (facebook.com|twitter.com)) {
            return 403;  # 如果是，返回403 Forbidden响应
        }

        proxy_pass http://$http_host$request_uri;
        proxy_set_header Host $http_host;
    }
}

📝 操作流程：

1. 客户端尝试访问facebook.com。
2. 请求首先发送到在8080端口上的Nginx正向代理。
3. 代理检查请求的Host是否为facebook.com或twitter.com。
4. 由于请求的是facebook.com，代理返回一个403 Forbidden响应，表示该请求被禁止。

---

2️⃣ 内容过滤：

🔍 示例：过滤包含关键词confidential的响应内容。

# 注意: 这是一个简化示例，实际实现可能需要第三方模块或更复杂的配置
server {
    listen 8080;

    location / {
        proxy_pass http://$http_host$request_uri;
        proxy_set_header Host $http_host;

        # 存储响应在变量中
        proxy_buffering on;
        proxy_buffers 1 1m;
        proxy_store /tmp/$binary_remote_addr;

        if ($upstream_http_body ~* confidential) {
            return 403;
        }
    }
}

📝 操作流程：

1. 客户端请求某个资源。
2. 请求首先发送到8080端口上的Nginx正向代理。
3. 代理将请求转发到目标服务器。
4. 当响应返回时，代理检查响应内容是否包含关键词confidential。
5. 如果找到，代理返回403 Forbidden响应。

---

3️⃣ 缓存：

🚀 示例：缓存外部网站响应1小时。

server {
    listen 8080;

    location / {
        proxy_pass http://$http_host$request_uri;
        proxy_set_header Host $http_host;

        proxy_cache my_cache;
        proxy_cache_valid 200 302 1h; 
    }
}

# 定义缓存路径和大小
proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=1g 
                 inactive=60m use_temp_path=off;

📝 操作流程：

1. 客户端请求某个资源。
2. 请求首先发送到8080端口上的Nginx正向代理。
3. 如果资源已缓存且未过期，代理直接从缓存返回资源。
4. 如果未缓存或缓存已过期，代理从目标服务器获取资源，将其缓存，并传递给客户端。

---

4️⃣ 匿名浏览：

🕵️ 示例：使用代理隐藏客户端的真实IP。

server {
    listen 8080;

    location / {
        proxy_pass http://$http_host$request_uri;

        # 清除客户端原始IP信息
        proxy_set_header X-Real-IP "";
        proxy_set_header X-Forwarded-For "";
        proxy_set_header Host $http_host;
    }
}

📝 操作流程：

1. 客户端请求某个资源。
2. 请求首先发送到8080端口上的Nginx正向代理。
3. 代理清除关于客户端真实IP的所有头信息。
4. 代理将请求转发到目标服务器，但目标服务器无法知道客户端的真实IP。

---

🏥 运行状况检查 (Health Checks)

Nginx Plus 提供了运行状况检查功能，它可以自动检测后端服务器的健康状况并在必要时进行故障转移。

location / {
    proxy_pass http://myapp0;
    health_check;  # ✅ 这里启用了健康检查
}

上述配置中，我们在一个 location 块中定义了反向代理规则，将请求传递给名为 myapp0 的上游服务器组。此处的重点是 health_check; 指令，它启用了健康检查功能。

运行状况检查的工作原理如下：

1. 🔄 定期检查健康状态：Nginx Plus 会定期向配置的后端服务器发送健康检查请求，以确定服务器是否处于健康状态。

2. 🚀 健康检查请求：Nginx 会向后端服务器发送健康检查请求（通常是 HTTP HEAD 请求），并等待响应。服务器的响应代码和响应时间将被用来判断服务器的健康状况。

3. 📊 健康状态判定：根据服务器的响应，Nginx 会将服务器划分为以下几种状态：

   • ✅ Healthy（健康）：服务器响应正常，状态为健康。
   • ❌ Unhealthy（不健康）：服务器响应异常，可能是响应码不正常或响应时间过长。
   • 🔄 Checking（检查中）：服务器正在进行健康检查，尚未确定状态。
   • 🚫 Unavailable（不可用）：服务器已被标记为不可用，不再接收流量。

4. 🚑 故障转移：如果某个后端服务器被标记为不可用（Unhealthy 或 Unavailable），Nginx 将自动将流量重新路由到其他健康的服务器，从而实现故障转移。

通过使用健康检查，Nginx Plus 可以确保只有健康的后端服务器接收流量，从而提高了系统的可用性和可靠性。这是一个关键的功能，特别是在大规模的生产环境中，可以帮助自动应对后端服务器的故障。

---