08-04-2023, 04:27 PM
通过多种算法和高级功能（例如慢启动和会话持久性）对 Web 或应用程序服务器组之间的 HTTP 流量进行负载平衡。
概述
跨多个应用程序实例的负载平衡是优化资源利用率、最大化吞吐量、减少延迟和确保容错配置的常用技术。
点播观看NGINX Plus 负载均衡和扩展网络研讨会，深入了解 NGINX 用户用来构建大规模、高度可用的 Web 服务的技术。
NGINX 和 NGINX Plus 可以作为非常高效的 HTTP 负载均衡器用于不同的部署场景。
将 HTTP 流量代理到一组服务器
要开始使用 NGINX Plus 或 NGINX Open Source 对一组服务器的 HTTP 流量进行负载平衡，首先需要使用指令定义该组upstream。该指令被放置在http上下文中。
组中的服务器使用指令进行配置server（不要与server定义在 NGINX 上运行的虚拟服务器的块混淆）。例如，以下配置定义了一个名为backend的组，并由三个服务器配置组成（可能在三个以上的实际服务器中解析）：
proxy_pass要将请求传递到服务器组，请在指令（或这些协议的fastcgi_pass、memcached_pass、scgi_pass或指令）中指定组的名称uwsgi_pass。在下一个示例中，NGINX 上运行的虚拟服务器将所有请求传递到后端上游组在前面的示例中定义：
以下示例结合了上面的两个代码片段，展示了如何将 HTTP 请求代理到后端服务器组。该组由三台服务器组成，其中两台运行同一应用程序的实例，而第三台是备份服务器。由于块中没有指定负载均衡算法upstream，NGINX 使用默认算法 Round Robin：
选择负载平衡方法
NGINX Open Source 支持四种负载均衡方法，NGINX Plus 添加了另外两种方法：
服务器重量
默认情况下，NGINX 使用循环方法根据权重在组中的服务器之间分配请求。该指令weight的参数server设置服务器的权重；默认是1：
在示例中，backend1.example.com 的权重为5；另外两台服务器具有默认权重 ( 1)，但有 IP 地址的服务器192.0.0.1被标记为backup服务器，除非其他两台服务器都不可用，否则不会接收请求。通过这种权重配置，每个6请求5都会发送到backend1.example.com和1backend2.example.com 。
服务器慢启动
服务器慢启动功能可防止最近恢复的服务器被连接淹没，连接可能会超时并导致服务器再次被标记为故障。
0在 NGINX Plus 中，慢启动允许上游服务器在恢复或可用后逐渐将其权重恢复到其标称值。slow_start这可以通过指令的参数来完成server：
时间值（此处为30秒）设置 NGINX Plus 将服务器连接数增加到满值的时间。
请注意，如果组中只有一个服务器，则该指令的max_fails、fail_timeout和slow_start参数server将被忽略，并且该服务器永远不会被视为不可用。
启用会话保持
会话持久性意味着 NGINX Plus 识别用户会话并将给定会话中的所有请求路由到同一上游服务器。
NGINX Plus 支持三种会话持久方法。这些方法是用sticky指令设置的。（对于 NGINX Open Source 的会话持久性，请使用如上所述的orhash指令。）ip_hash
EXAMPLECOOKIE在示例中，其中一台上游服务器通过在响应中设置 cookie 来创建会话。
强制create参数指定一个变量，该变量指示如何创建新会话。在示例中，新会话是EXAMPLECOOKIE根据上游服务器发送的 cookie 创建的。
强制lookup参数指定如何搜索现有会话。EXAMPLECOOKIE在我们的示例中，在客户端发送的cookie 中搜索现有会话。
强制zone参数指定一个共享内存区域，其中保存有关粘性会话的所有信息。在我们的示例中，该区域名为client_sessions，1 大小为兆字节。
这是比前两种更复杂的会话持久方法，因为它不需要在客户端保留任何 cookie：所有信息都保存在服务器端的共享内存区域中。
如果集群中有多个使用“粘性学习”方法的 NGINX 实例，则可以在满足以下条件的情况下同步其共享内存区域的内容：
限制连接数
使用 NGINX Plus，可以通过参数指定最大数量来限制与上游服务器的活动连接数量max_conns。
如果max_conns达到限制，请求将被放入队列中以供进一步处理，前提是queue还包含该指令来设置队列中可以同时处理的最大请求数：
如果队列已满请求或在可选timeout参数指定的超时时间内无法选择上游服务器，客户端会收到错误。
max_conns请注意，如果keepalive在 other 中打开了空闲连接，则该限制将被忽略worker processes。因此，与服务器的连接总数可能会超过与多个工作进程共享max_conns内存的配置中的值。
配置健康检查
NGINX 可以持续测试您的 HTTP 上游服务器，避免出现故障的服务器，并将恢复的服务器正常添加到负载平衡组中。
有关如何配置HTTP 运行状况检查的说明，请参阅HTTP 运行状况检查。
与多个工作进程共享数据
如果upstream块不包含该zone指令，则每个工作进程都会保留自己的服务器组配置副本，并维护自己的一组相关计数器。计数器包括组中每个服务器的当前连接数以及将请求传递到服务器的失败尝试次数。因此，服务器组配置无法动态修改。
当该zone指令包含在upstream块中时，上游组的配置将保存在所有工作进程共享的内存区域中。此场景是动态可配置的，因为工作进程访问组配置的相同副本并使用相同的相关计数器。
该zone指令对于上游组的主动健康检查和动态重新配置是强制性的。然而，上游组的其他功能也可以从该指令的使用中受益。
例如，如果组的配置不共享，则每个工作进程都会维护自己的计数器，以记录向服务器传递请求的失败尝试（由 max_fails 参数设置）。在这种情况下，每个请求仅到达一个工作进程。当被选择处理请求的工作进程未能将请求传输到服务器时，其他工作进程对此一无所知。虽然某些工作进程可能认为服务器不可用，但其他工作进程仍可能向该服务器发送请求。对于要明确认为服务器不可用的服务器，在参数设置的时间范围内失败尝试的次数fail_timeout必须等于max_fails工作进程数的乘积。另一方面，该zone指令保证了预期的行为。
同样，如果没有该指令， “最少连接”负载平衡方法可能无法按预期工作zone，至少在低负载下是这样。该方法将请求传递给活动连接数最少的服务器。如果组的配置不共享，则每个工作进程使用自己的连接数计数器，并且可能将请求发送到另一个工作进程刚刚向其发送请求的同一服务器。但是，您可以增加请求数量来减少这种影响。在高负载下，请求在工作进程之间均匀分配，并且该Least Connections方法按预期工作。
设置区域大小
由于使用模式差异很大，因此无法推荐理想的内存区域大小。所需的内存量取决于启用哪些功能（例如会话持久性、运行状况检查或DNS 重新解析）以及如何识别上游服务器。
例如，在sticky_route启用会话持久方法和单个运行状况检查的情况下，256 KB 区域可以容纳有关指定数量的上游服务器的信息：
使用 DNS 配置 HTTP 负载平衡
可以使用 DNS 在运行时修改服务器组的配置。
对于指令中用域名标识的上游组中的服务器server，NGINX Plus 可以监控相应 DNS 记录中 IP 地址列表的更改，并自动将更改应用到上游组的负载平衡，而无需重新开始。resolver这可以通过在块中包含指令http以及指令resolve的参数来完成server：
在示例中，指令resolve的参数告诉 NGINX Plus 定期将backend1.example.com和backend2.example.com域名server重新解析为 IP 地址。
该resolver指令定义 NGINX Plus 向其发送请求的 DNS 服务器的 IP 地址（此处为10.0.0.1）。默认情况下，NGINX Plus 按照记录中的生存时间 (TTL) 指定的频率重新解析 DNS 记录，但您可以使用参数覆盖 TTL 值valid；在示例中，它是300秒或5分钟。
可选ipv6=off参数表示仅使用 IPv4 地址进行负载平衡，但默认情况下支持解析 IPv4 和 IPv6 地址。
如果一个域名解析为多个IP地址，这些地址将保存到上游配置并进行负载均衡。在我们的示例中，服务器根据最少连接负载平衡方法进行负载平衡。如果服务器的 IP 地址列表发生更改，NGINX Plus 会立即开始在新地址集之间进行负载平衡。
Microsoft Exchange 服务器的负载平衡
在NGINX Plus R7及更高版本中，NGINX Plus 可以将 Microsoft Exchange 流量代理到一台服务器或一组服务器并对其进行负载平衡。
要设置 Microsoft Exchange 服务器的负载平衡：
完整的 NTLM 示例
有关配置 Microsoft Exchange 和 NGINX Plus 的更多信息，请参阅使用 NGINX Plus 负载平衡 Microsoft Exchange 服务器部署指南。
使用 NGINX Plus API 进行动态配置
借助 NGINX Plus，可以使用 NGINX Plus API 动态修改上游服务器组的配置。配置命令可用于查看所有服务器或组中的特定服务器、修改特定服务器的参数以及添加或删除服务器。
概述
跨多个应用程序实例的负载平衡是优化资源利用率、最大化吞吐量、减少延迟和确保容错配置的常用技术。
点播观看NGINX Plus 负载均衡和扩展网络研讨会，深入了解 NGINX 用户用来构建大规模、高度可用的 Web 服务的技术。
NGINX 和 NGINX Plus 可以作为非常高效的 HTTP 负载均衡器用于不同的部署场景。
将 HTTP 流量代理到一组服务器
要开始使用 NGINX Plus 或 NGINX Open Source 对一组服务器的 HTTP 流量进行负载平衡，首先需要使用指令定义该组upstream。该指令被放置在http上下文中。
组中的服务器使用指令进行配置server（不要与server定义在 NGINX 上运行的虚拟服务器的块混淆）。例如，以下配置定义了一个名为backend的组，并由三个服务器配置组成（可能在三个以上的实际服务器中解析）：
代码:
http {
upstream backend {
server backend1.example.com weight=5;
server backend2.example.com;
server 192.0.0.1 backup;
}
}proxy_pass要将请求传递到服务器组，请在指令（或这些协议的fastcgi_pass、memcached_pass、scgi_pass或指令）中指定组的名称uwsgi_pass。在下一个示例中，NGINX 上运行的虚拟服务器将所有请求传递到后端上游组在前面的示例中定义：
代码:
server {
location / {
proxy_pass http://backend;
}
}以下示例结合了上面的两个代码片段，展示了如何将 HTTP 请求代理到后端服务器组。该组由三台服务器组成，其中两台运行同一应用程序的实例，而第三台是备份服务器。由于块中没有指定负载均衡算法upstream，NGINX 使用默认算法 Round Robin：
代码:
http {
upstream backend {
server backend1.example.com;
server backend2.example.com;
server 192.0.0.1 backup;
}
server {
location / {
proxy_pass http://backend;
}
}
}选择负载平衡方法
NGINX Open Source 支持四种负载均衡方法，NGINX Plus 添加了另外两种方法：
- 循环法 – 请求在服务器之间均匀分布，并考虑服务器权重。默认情况下使用此方法（没有启用它的指令）：
代码:upstream backend {
# no load balancing method is specified for Round Robin
server backend1.example.com;
server backend2.example.com;
} - 最少连接– 请求发送到活动连接数最少的服务器，同样考虑服务器权重：
代码:upstream backend {
least_conn;
server backend1.example.com;
server backend2.example.com;
} - IP 哈希– 根据客户端 IP 地址确定请求发送到的服务器。在这种情况下，将使用 IPv4 地址的前三个八位字节或整个 IPv6 地址来计算哈希值。该方法保证来自同一地址的请求到达同一服务器，除非该服务器不可用。
如果其中一台服务器需要暂时从负载平衡轮换中删除，则可以使用down参数对其进行标记，以保留客户端 IP 地址的当前哈希值。本服务器要处理的请求会自动发送到组中的下一个服务器：代码:upstream backend {
ip_hash;
server backend1.example.com;
server backend2.example.com;
}
代码:upstream backend {
server backend1.example.com;
server backend2.example.com;
server backend3.example.com down;
} - 通用哈希– 请求发送到的服务器由用户定义的键确定，该键可以是文本字符串、变量或组合。例如，密钥可以是配对的源 IP 地址和端口，或者是 URI，如下例所示：
该指令的可选一致性参数hash可实现ketama一致性哈希负载平衡。请求根据用户定义的散列键值均匀分布在所有上游服务器上。如果将上游服务器添加到上游组或从上游组中删除，则仅重新映射几个键，这可以最大限度地减少负载平衡缓存服务器或其他累积状态的应用程序的缓存未命中情况。代码:upstream backend {
hash $request_uri consistent;
server backend1.example.com;
server backend2.example.com;
}
- 最短时间（仅限 NGINX Plus）——对于每个请求，NGINX Plus 选择平均延迟最低和活动连接数最少的服务器，其中最低平均延迟是根据指令中包含的以下参数来计算的：least_time
- header– 从服务器接收第一个字节的时间
- last_byte– 从服务器接收完整响应的时间
- last_byte inflight– 考虑到不完整的请求，从服务器接收完整响应的时间
代码:upstream backend {
least_time header;
server backend1.example.com;
server backend2.example.com;
} - header– 从服务器接收第一个字节的时间
- 随机– 每个请求将被传递到随机选择的服务器。如果two指定了该参数，首先NGINX会根据服务器权重随机选择两台服务器，然后使用指定的方法选择其中一台服务器：
- least_conn– 最少的活动连接数
- least_time=header(NGINX Plus) – 从服务器接收响应头的最短平均时间 ( $upstream_header_time)
- least_time=last_byte(NGINX Plus) – 从服务器接收完整响应的最短平均时间 ( $upstream_response_time)
随机负载平衡方法应用于多个负载平衡器将请求传递到同一组后端的分布式环境。对于负载均衡器具有所有请求的完整视图的环境，请使用其他负载均衡方法，例如循环法、最少连接数和最少时间。代码:upstream backend {
random two least_time=last_byte;
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
server backend4.example.com;
}
- least_conn– 最少的活动连接数
引用:注意：配置除循环之外的任何方法时，请将相应的指令（hash、ip_hash、least_conn、least_time或）放在块中指令random列表的上方。serverupstream {}
服务器重量
默认情况下，NGINX 使用循环方法根据权重在组中的服务器之间分配请求。该指令weight的参数server设置服务器的权重；默认是1：
代码:
upstream backend {
server backend1.example.com weight=5;
server backend2.example.com;
server 192.0.0.1 backup;
}在示例中，backend1.example.com 的权重为5；另外两台服务器具有默认权重 ( 1)，但有 IP 地址的服务器192.0.0.1被标记为backup服务器，除非其他两台服务器都不可用，否则不会接收请求。通过这种权重配置，每个6请求5都会发送到backend1.example.com和1backend2.example.com 。
服务器慢启动
服务器慢启动功能可防止最近恢复的服务器被连接淹没，连接可能会超时并导致服务器再次被标记为故障。
0在 NGINX Plus 中，慢启动允许上游服务器在恢复或可用后逐渐将其权重恢复到其标称值。slow_start这可以通过指令的参数来完成server：
代码:
upstream backend {
server backend1.example.com slow_start=30s;
server backend2.example.com;
server 192.0.0.1 backup;
}时间值（此处为30秒）设置 NGINX Plus 将服务器连接数增加到满值的时间。
请注意，如果组中只有一个服务器，则该指令的max_fails、fail_timeout和slow_start参数server将被忽略，并且该服务器永远不会被视为不可用。
启用会话保持
会话持久性意味着 NGINX Plus 识别用户会话并将给定会话中的所有请求路由到同一上游服务器。
NGINX Plus 支持三种会话持久方法。这些方法是用sticky指令设置的。（对于 NGINX Open Source 的会话持久性，请使用如上所述的orhash指令。）ip_hash
- 粘性 cookie – NGINX Plus 将会话 cookie 添加到来自上游组的第一个响应中，并标识发送响应的服务器。客户端的下一个请求包含 cookie 值，NGINX Plus 将该请求路由到响应第一个请求的上游服务器：
在示例中，srv_id参数设置 cookie 的名称。可选expires参数设置浏览器保留 cookie 的时间（此处为1小时）。可选domain参数定义设置 cookie 的域，可选path参数定义设置 cookie 的路径。这是最简单的会话保持方法。代码:upstream backend {
server backend1.example.com;
server backend2.example.com;
sticky cookie srv_id expires=1h domain=.example.com path=/;
}
- 粘性路由– NGINX Plus 在收到第一个请求时为客户端分配一条“路由”。所有后续请求都会与指令route的参数进行比较server，以识别请求代理到的服务器。路由信息取自 cookie 或请求 URI。
代码:upstream backend {
server backend1.example.com route=a;
server backend2.example.com route=b;
sticky route $route_cookie $route_uri;
} - 粘性学习方法 – NGINX Plus 首先通过检查请求和响应来查找会话标识符。然后NGINX Plus“学习”哪个上游服务器对应哪个会话标识符。通常，这些标识符在 HTTP cookie 中传递。如果请求包含已经“学习”的会话标识符，NGINX Plus 会将请求转发到相应的服务器：
代码:upstream backend {
server backend1.example.com;
server backend2.example.com;
sticky learn
create=$upstream_cookie_examplecookie
lookup=$cookie_examplecookie
zone=client_sessions:1m
timeout=1h;
}
EXAMPLECOOKIE在示例中，其中一台上游服务器通过在响应中设置 cookie 来创建会话。
强制create参数指定一个变量，该变量指示如何创建新会话。在示例中，新会话是EXAMPLECOOKIE根据上游服务器发送的 cookie 创建的。
强制lookup参数指定如何搜索现有会话。EXAMPLECOOKIE在我们的示例中，在客户端发送的cookie 中搜索现有会话。
强制zone参数指定一个共享内存区域，其中保存有关粘性会话的所有信息。在我们的示例中，该区域名为client_sessions，1 大小为兆字节。
这是比前两种更复杂的会话持久方法，因为它不需要在客户端保留任何 cookie：所有信息都保存在服务器端的共享内存区域中。
如果集群中有多个使用“粘性学习”方法的 NGINX 实例，则可以在满足以下条件的情况下同步其共享内存区域的内容：
- 这些区域具有相同的名称
- 该zone_sync功能是在每个实例上配置的
- 参数sync已指定
代码:
sticky learn
create=$upstream_cookie_examplecookie
lookup=$cookie_examplecookie
zone=client_sessions:1m
timeout=1h
sync;
}限制连接数
使用 NGINX Plus，可以通过参数指定最大数量来限制与上游服务器的活动连接数量max_conns。
如果max_conns达到限制，请求将被放入队列中以供进一步处理，前提是queue还包含该指令来设置队列中可以同时处理的最大请求数：
代码:
upstream backend {
server backend1.example.com max_conns=3;
server backend2.example.com;
queue 100 timeout=70;
}如果队列已满请求或在可选timeout参数指定的超时时间内无法选择上游服务器，客户端会收到错误。
max_conns请注意，如果keepalive在 other 中打开了空闲连接，则该限制将被忽略worker processes。因此，与服务器的连接总数可能会超过与多个工作进程共享max_conns内存的配置中的值。
配置健康检查
NGINX 可以持续测试您的 HTTP 上游服务器，避免出现故障的服务器，并将恢复的服务器正常添加到负载平衡组中。
有关如何配置HTTP 运行状况检查的说明，请参阅HTTP 运行状况检查。
与多个工作进程共享数据
如果upstream块不包含该zone指令，则每个工作进程都会保留自己的服务器组配置副本，并维护自己的一组相关计数器。计数器包括组中每个服务器的当前连接数以及将请求传递到服务器的失败尝试次数。因此，服务器组配置无法动态修改。
当该zone指令包含在upstream块中时，上游组的配置将保存在所有工作进程共享的内存区域中。此场景是动态可配置的，因为工作进程访问组配置的相同副本并使用相同的相关计数器。
该zone指令对于上游组的主动健康检查和动态重新配置是强制性的。然而，上游组的其他功能也可以从该指令的使用中受益。
例如，如果组的配置不共享，则每个工作进程都会维护自己的计数器，以记录向服务器传递请求的失败尝试（由 max_fails 参数设置）。在这种情况下，每个请求仅到达一个工作进程。当被选择处理请求的工作进程未能将请求传输到服务器时，其他工作进程对此一无所知。虽然某些工作进程可能认为服务器不可用，但其他工作进程仍可能向该服务器发送请求。对于要明确认为服务器不可用的服务器，在参数设置的时间范围内失败尝试的次数fail_timeout必须等于max_fails工作进程数的乘积。另一方面，该zone指令保证了预期的行为。
同样，如果没有该指令， “最少连接”负载平衡方法可能无法按预期工作zone，至少在低负载下是这样。该方法将请求传递给活动连接数最少的服务器。如果组的配置不共享，则每个工作进程使用自己的连接数计数器，并且可能将请求发送到另一个工作进程刚刚向其发送请求的同一服务器。但是，您可以增加请求数量来减少这种影响。在高负载下，请求在工作进程之间均匀分配，并且该Least Connections方法按预期工作。
设置区域大小
由于使用模式差异很大，因此无法推荐理想的内存区域大小。所需的内存量取决于启用哪些功能（例如会话持久性、运行状况检查或DNS 重新解析）以及如何识别上游服务器。
例如，在sticky_route启用会话持久方法和单个运行状况检查的情况下，256 KB 区域可以容纳有关指定数量的上游服务器的信息：
- 128 个服务器（每个服务器定义为 IP 地址:端口对）
- 88 个服务器（每个服务器定义为主机名：端口对，其中主机名解析为单个 IP 地址）
- 12 个服务器（每个服务器定义为主机名：端口对，其中主机名解析为多个 IP 地址）
使用 DNS 配置 HTTP 负载平衡
可以使用 DNS 在运行时修改服务器组的配置。
对于指令中用域名标识的上游组中的服务器server，NGINX Plus 可以监控相应 DNS 记录中 IP 地址列表的更改，并自动将更改应用到上游组的负载平衡，而无需重新开始。resolver这可以通过在块中包含指令http以及指令resolve的参数来完成server：
代码:
http {
resolver 10.0.0.1 valid=300s ipv6=off;
resolver_timeout 10s;
server {
location / {
proxy_pass http://backend;
}
}
upstream backend {
zone backend 32k;
least_conn;
# ...
server backend1.example.com resolve;
server backend2.example.com resolve;
}
}在示例中，指令resolve的参数告诉 NGINX Plus 定期将backend1.example.com和backend2.example.com域名server重新解析为 IP 地址。
该resolver指令定义 NGINX Plus 向其发送请求的 DNS 服务器的 IP 地址（此处为10.0.0.1）。默认情况下，NGINX Plus 按照记录中的生存时间 (TTL) 指定的频率重新解析 DNS 记录，但您可以使用参数覆盖 TTL 值valid；在示例中，它是300秒或5分钟。
可选ipv6=off参数表示仅使用 IPv4 地址进行负载平衡，但默认情况下支持解析 IPv4 和 IPv6 地址。
如果一个域名解析为多个IP地址，这些地址将保存到上游配置并进行负载均衡。在我们的示例中，服务器根据最少连接负载平衡方法进行负载平衡。如果服务器的 IP 地址列表发生更改，NGINX Plus 会立即开始在新地址集之间进行负载平衡。
Microsoft Exchange 服务器的负载平衡
在NGINX Plus R7及更高版本中，NGINX Plus 可以将 Microsoft Exchange 流量代理到一台服务器或一组服务器并对其进行负载平衡。
要设置 Microsoft Exchange 服务器的负载平衡：
- 在location块中，使用以下指令配置对上游 Microsoft Exchange 服务器组的代理proxy_pass：
代码:location / {
proxy_pass https://exchange;
# ...
} - 为了使 Microsoft Exchange 连接传递到上游服务器，请在块中将指令值location设置为，并将指令设置为，就像保持活动连接一样：
代码:proxy_http_version1.1proxy_set_headerConnection ""
location / {
# ...
proxy_http_version 1.1;
proxy_set_header Connection "";
# ...
} - 在该http块中，配置 Microsoft Exchange 服务器的上游组，upstream其名称与步骤 1 中的指令指定的上游组相同。proxy_pass然后指定指令ntlm以允许组中的服务器接受使用 NTLM 身份验证的请求：
代码:http {
# ...
upstream exchange {
zone exchange 64k;
ntlm;
# ...
}
} - 将 Microsoft Exchange 服务器添加到上游组并可选择指定负载平衡方法：
代码:http {
# ...
upstream exchange {
zone exchange 64k;
ntlm;
server exchange1.example.com;
server exchange2.example.com;
# ...
}
}
完整的 NTLM 示例
代码:
http {
# ...
upstream exchange {
zone exchange 64k;
ntlm;
server exchange1.example.com;
server exchange2.example.com;
}
server {
listen 443 ssl;
ssl_certificate /etc/nginx/ssl/company.com.crt;
ssl_certificate_key /etc/nginx/ssl/company.com.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
location / {
proxy_pass https://exchange;
proxy_http_version 1.1;
proxy_set_header Connection "";
}
}
}有关配置 Microsoft Exchange 和 NGINX Plus 的更多信息，请参阅使用 NGINX Plus 负载平衡 Microsoft Exchange 服务器部署指南。
使用 NGINX Plus API 进行动态配置
借助 NGINX Plus，可以使用 NGINX Plus API 动态修改上游服务器组的配置。配置命令可用于查看所有服务器或组中的特定服务器、修改特定服务器的参数以及添加或删除服务器。
