Nginx HTTP 代理、负载均衡、缓冲和缓存：概述

介绍

Nginx 是一款高性能的 Web 服务器，同时也用作反向代理、邮件代理、负载均衡器和 HTTP 缓存。Nginx 是免费且开源的，允许任何人下载并在其服务器环境中使用。

您可能已经使用过 Nginx 来托管网站。在本教程中，我们将讨论 Nginx 的其他功能。Nginx 的 HTTP 代理 功能允许它将请求传递给后端 HTTP 服务器进行处理。利用此功能，您可以设置多个后端服务器。它允许您根据需要扩展基础设施，以应对客户端请求的激增。

随着教程的深入，您将学习如何使用 Nginx 的 负载均衡 属性、缓冲 以及 缓存 响应来提高服务器性能，并确保为客户端提供更好的体验。让我们开始吧！

首先，要开始使用 Nginx，请查看我们的 关于如何在 Ubuntu 服务器上安装 Nginx 的教程.

关于代理的一般信息

如果您对 Web 服务器的了解仅限于处理网站请求和提供网页，您可能会想知道为什么我们需要代理请求。下面我们将解释其背后的原因。

从 Nginx 将请求代理到其他服务器的一个原因是为了支持基础设施的可扩展性。Nginx 默认并发处理许多连接。这使其非常适合作为客户端的第一接触点。然后，它可以将请求传递给各个后端服务器，以处理客户端请求的实际处理。这就是分担负载的方式。因此，它确保您可以尽可能地扩展基础设施。它还使您能够在其他服务器继续提供请求服务的同时，关闭某些服务器进行维护。

您可能希望将请求代理到其他服务器的第二个原因是，当您在生产环境中使用不适合直接处理客户端请求的应用服务器时。包括 Web 服务器在内的几种框架并不适合像 Nginx 那样的高性能。让 Nginx 作为入口点并将请求代理到这些低性能服务器，可以确保您的用户获得更好的体验。此外，它还可以保证提高应用程序的安全性。

在 Nginx 中代理请求的过程涉及处理来自 Nginx 服务器的请求，并将其传递给其他后端服务器进行实际处理。一旦其他后端服务器处理了请求，它们就会将结果传回给 Nginx。然后，Nginx 将结果作为响应发送给客户端。在这种情况下，客户端是 Web 浏览器，甚至是移动 Web 应用。其他后端服务器可以是无法在互联网上公开访问的本地服务器、远程服务器，甚至是 Nginx 服务器块配置中的其他虚拟服务器。Nginx 代理请求的这些其他服务器被称为 上游服务器.

Nginx 可以将请求代理到使用多种协议进行通信的服务器，包括 HTTP(S)、Memcached, SCGI, FastCGI、以及 uWSGI。对于每种类型的协议，都有一组指令。我们本教程的重点是 HTTP 协议。Nginx 将请求和消息组件解析为上游服务器可以解释和处理的格式。

分析基本的 HTTP 代理转发

最简单的代理类型涉及将请求传递给通过 HTTP 通信的单个服务器。这种类型的代理通常被称为“代理转发”（proxy pass），它由 Nginx 配置文件中命名贴切的 proxy_pass 指令处理。

proxy_pass 指令出现在 location 块中。它也存在于 location 上下文的块和 limit_except 上下文中。当请求与包含 proxy_pass 指令的 location 匹配时，请求将转到该指令指定的 URL。以下是配置片段的示例：

在上述示例中，对端口 80 的请求将转到 localhost:3000：

上方的屏幕截图显示了尝试访问 localhost 时的默认 Nginx 页面。在使用 proxy pass 指令重新启动 Nginx 服务器后，所有请求都将转到端口 3000。一个演示应用程序正在端口 3000 上运行，您可以从下面的图片中看到，并且可以直接从 localhost 访问而无需指定端口：

在下一个示例中，在 proxy_pass 定义的服务器末尾没有指定 URI。对于符合此模式的定义，客户端请求的 URI 将原样传递给上游服务器。

例如，当此块处理对 /match/url/here 的请求时，请求 URI 将作为 http://example.com/match/url/here 发送到 example.com 服务器。

以下是备用配置片段的示例：

正如您在上面的片段中看到的，我们在代理服务器的末尾定义了一个 URI 段为 new/url/prefix。当您在 proxy_pass 定义中定义 URI 时，在转到上游服务器进行处理时，请求中与 location 定义匹配的部分将被此 URI 替换。

例如，对 Nginx 服务器上 /match/url/here 的请求将作为 http://example.com/new/url/here 传递给上游服务器。/match/url 被替换为 /new/url。请记住这一点。

在某些情况下，无法像上面那样传递 URI。在这些情况下，Nginx 会忽略 proxy_pass 定义末尾的 URI。最终，客户端的原始 URI 或其他指令修改后的 URI 将被传递给上游服务器。

一个例子是当正则表达式匹配 location 时。Nginx 可能无法确定 URI 的哪一部分与表达式匹配。因此，它会发送原始的客户端请求 URI。这会导致在同一个块中重写和处理客户端 URI。在这种情况下，将传递重写后的 URI。

Nginx 如何处理请求头？

请求头对于服务器如何处理请求至关重要。某些请求头可能包含身份验证信息。因此，我们必须了解 Nginx 代理将如何处理这些请求头。从 Nginx 到上游服务器的代理请求看起来会与直接来自客户端的请求不同。其中一些差异是由于随代理请求一起发送的请求头造成的。

在代理请求期间，Nginx 将对其从客户端接收到的请求头进行调整。其中一些调整包括：

• 清除所有空请求头。空请求头只会使请求膨胀，因此没有必要将它们传递给上游服务器。

• 默认情况下，任何包含下划线的请求头都被视为无效，因此会从请求中删除。如果您想更改此行为并允许 Nginx 将带有下划线的请求头解释为有效，则可以将 underscores_in_headers 指令指定为 “on”。如果不这样做，那么来自客户端的此类请求头将永远无法到达上游服务器。

• “Host” 请求头将被重写为由 $proxy_host 变量指定的值。这是由 proxy_pass 指令指定的上游服务器的 IP 地址或名称以及端口号。

• “Connection” 请求头的值更改为 “close”。Connection 请求头保存有关在两方之间建立的特定连接的信息。当 Nginx 将其值设置为 close 时，它向上游服务器指示一旦对原始请求做出响应，连接就会关闭，因此不应期望它是持久连接。

以下是我们可以从上面概述的代理请求头调整中注意到的一些要点：

• 如果您不希望将请求头传递给上游服务器，将其设置为空字符串将完全从请求中删除该请求头。

• 如果上游服务器中的应用程序将处理非标准请求头，请确保这些请求头中不包含下划线。或者，您可以在配置中将 underscores_in_headers 指令设置为 “on”（这在 IP 地址/端口组合的默认服务器声明上下文中或在 HTTP 上下文中均有效）。这样做将确保这些请求头不会被标记为无效，从而能够实际传递给上游服务器。

• 在大多数代理情况下，“Host” 请求头非常重要。默认情况下，它被设置为 $proxy_host 的值，该变量包含从 proxy_pass 规范中检索到的域名或 IP 地址和端口。此地址是默认选择的，并直接从连接信息中提取。这是 Nginx 唯一能保证上游服务器会做出响应的地址。

以下是 “Host” 请求头最常用的值：

• $host – 按照优先级顺序，该变量被设置为请求行本身的主机名、来自客户端请求的 “Host” 请求头，或者与请求匹配的服务器名称。

• $http_host – 该变量将 “Host” 请求头设置为来自客户端请求的 “Host” 请求头。客户端请求中的请求头在 Nginx 中始终可以作为变量使用。这些变量以 $http_ 前缀开头，后跟小写的请求头名称。虽然 $http_host 变量在大多数情况下都能正常工作，但当客户端请求缺少有效的 “Host” 请求头时，可能会导致传递失败。

• $proxy_host – 该变量将 “Host” 请求头设置为从 proxy_pass 的规范中检索到的域名或 IP 地址与端口的组合。从 Nginx 的角度来看，这是默认行为，因此被认为是安全的。然而，这可能不是服务器正确处理请求所需要的。

大多数配置都会将 “Host” 请求头设置为 $host 变量。它非常灵活，并将为上游服务器提供准确填充的请求头。

设置和修改请求头

proxy_set_header 指令允许我们为代理连接设置或修改请求头。在前面讨论的 “Host” 请求头中，我们可以执行以下操作来修改和添加代理请求中常用的其他请求头：

在上述配置片段中，我们将 “Host” 请求头设置为 $host 变量，该变量包含有关所请求的原始主机的信息。我们为 X-Forwarded-Proto 请求头设置了来自客户端的原始请求的协议（schema）信息（这可以是 HTTP 或 HTTPS 请求）。

我们将客户端的实际 IP 地址传递给 X-Real-IP。这使上游服务器能够根据客户端的 IP 来源适当地做出决策或存储日志。X-Forwarded-For 请求头包含客户端在到达此位置之前所经过的所有代理服务器的 IP 地址列表。在上面的代码片段中，我们将其设置为 $proxy_add_x_forwarded_for 变量。该变量将获取从客户端获取的原始 X-Forwarded-For 请求头的值，并在末尾添加 Nginx 代理服务器的 IP 地址。

如果您希望在多个 location 中引用 proxy_set_header 指令，可以将其移至 server 或 http 上下文中。请参考下面的配置片段：

定义 Upstream 上下文以对代理连接进行负载均衡

至此，您已经了解了如何对单个后端上游服务器进行简单的 http 代理。值得庆幸的是，使用 Nginx，您可以通过定义后端服务器池来传递请求进行处理，从而扩展此类配置。

Nginx 提供了一个名为 upstream 的指令，用于定义服务器池。在该指令的配置中，您只需指定能够处理客户端请求的服务器。Nginx 作为代理服务器，允许以极少的努力扩展基础设施。upstream 指令必须在 Nginx 配置的 http 上下文中指定。

以下是显示 upstream 指令的示例：

在上面的配置代码片段中，我们定义了一个名为 several_backend_hosts 的 upstream 上下文。定义的上下文名称现在可以在 proxy_pass 中使用。它可以像普通域名一样使用，如示例所示。在 server 块中，我们将所有对 example.com/proxy-me/… 的请求传递给我们使用 upstream 指令定义的池，在本例中为 several_backend_hosts。通过应用可配置的算法，在池中选择一个主机来处理传入的请求。默认情况下，选择遵循 轮询（循环）过程 – 每个请求依次路由到不同的主机。

如何更改 Upstream 均衡算法

如上所述，选择过程遵循轮询过程。在本节中，我们将了解如何修改 upstream 池使用的均衡算法。要修改算法，您可以在 upstream 上下文中包含其他指令或标志，定义如下：

• （轮询）– 如果未指定其他 upstream 均衡指令，则默认情况下，在 upstream 上下文中定义的每个服务器将依次接收请求。

• least_conn – 此指令指示 upstream 选择活动连接数最少的后端服务器。这适用于连接到某个后端服务器可能会持续一段时间的情况。

• hash – 此指令在 memcached 代理中很常见。连接根据随机提供的哈希键的值传递给后端服务器。哈希键的值可以是变量、文本或两者的组合。hash 恰好是唯一需要用户输入作为哈希键的均衡方法。

• ip_hash – 此指令指示 upstream 根据客户端的 IP 地址将请求分配给不同的服务器。IP 地址的前三个八位字节是确定哪个服务器应该处理请求的键。该指令的一个优点是客户端每次往往会连接到同一台服务器，从而确保会话一致性。

以下是如何将均衡算法指令添加到 upstream 上下文的示例：

在上面的代码片段中，Nginx 将选择连接数最少的任意服务器来处理传入的请求。ip_hash 指令遵循相同的语法。对于 hash 指令，您必须提供一个自选的键来进行哈希，示例如下：

这里使用的哈希将是客户端’的 IP 地址和端口的结果。可选参数 consistent 实现了 ketama 一致性哈希算法。这可以确保在您更改上游服务器时，对缓存的影响降到最低。

如何指定服务器权重进行负载均衡

默认情况下，当您声明后端服务器时，每个服务器的权重是相等的。其假设是每个服务器都有资源和能力来处理相同数量的负载，当然，这是在考虑您在上游上下文中指定的任何均衡算法的情况下。要更改此默认行为，您可以在声明期间为每个服务器设置不同的权重。让我们来看一个例子：

在此示例中，host1.example.com 将接收其他两台服务器两倍的流量。默认情况下，每个服务器的权重为 1。

通过缓冲区释放后端服务器

在服务器配置中配置代理时，您可能会担心向进程中添加更多服务器会对性能产生影响。幸运的是，Nginx 具有缓冲和缓存功能，可以帮助减轻这些性能问题。

在代理到另一台服务器时，两种不同连接的速度肯定会影响客户端的体验：

• 第一种连接是从客户端到 Nginx 代理的连接。

• 第二种连接是从 Nginx 代理到后端上游服务器的连接。

Nginx 可以根据需要调整其行为，以帮助优化其中任何一种连接。

如果我们移除缓冲区，来自上游后端的数据会立即在 Nginx 代理处开始传输给客户端。如果您知道您的客户端速度很快，您可以完全关闭缓冲，以确保数据足够快地到达客户端。当您开启缓冲时，Nginx 代理会临时存储从后端上游服务器接收到的响应数据。然后，它会根据客户端的速度将数据发送给客户端。一旦 Nginx 的缓冲区中有了响应，它就可以关闭与后端服务器的连接。然后，它将以客户端支持的速度将数据分发给客户端。同时，它允许后端服务器继续处理其他传入的请求。

默认情况下，Nginx 会开启缓冲。这是因为我们无法知道客户端的连接速度。客户端往往有不同的连接，这些连接可能会比较慢。下面，我们将定义可以指定的各种指令，以调整 Nginx 的缓冲行为。这些指令可以在 http、server 或 location 上下文中定义，但是，您应该注意，大小调整指令是针对每个请求进行配置的。因此，在有太多传入客户端请求时，将它们增加到超出绝对必要的范围可能会影响服务器的性能。以下是这些指令：

• proxy_buffering – 该指令控制特定上下文及其子上下文的缓冲是否处于活动状态。proxy_buffering 的默认配置为“on”。

• proxy_buffer_size – 该指令指定用于存储从后端服务器响应中获取的标头（headers）的缓冲区大小。标头构成了后端服务器响应的第一部分。这些标头的缓冲与响应的其余部分是分开的。默认情况下，此缓冲区的大小与 proxy_buffers 的大小相同。但是，如果标头信息较小，您可以将该大小设置为较小的值。

• proxy_buffers – 该指令控制代理响应缓冲区的数量（第一个参数）和大小（第二个参数）。默认配置指定 8 个大小等于一个内存页（4k 或 8k）的缓冲区。您可以通过增加缓冲区数量来允许缓冲更多信息。

• proxy_max_temp_file_size – 该指令指定每个请求在磁盘上临时文件的最大大小。当上游响应太大而无法放入缓冲区时，就会创建临时文件。

• proxy_busy_buffers_size – 该指令指定可以传递为“客户端就绪”（client-ready）并因此处于繁忙状态的缓冲区的最大大小。客户端一次只能从一个缓冲区读取数据。但是，缓冲区会排队以批量发送给客户端。您可以通过修改此指令来指定允许处于此状态的缓冲区空间大小。

• proxy_temp_file_write_size – 该指令指定当来自后端上游服务器的响应太大而无法放入配置的缓冲区时，Nginx 一次写入临时文件的数据量。

• proxy_temp_path – 该指令指定当来自上游后端服务器的响应太大而无法放入配置的缓冲区时，Nginx 应在磁盘上存储任何临时文件的路径位置。

Nginx 具有高度可定制性，为您提供了几个指令来微调缓冲行为。在大多数情况下，默认值就可以很好地工作。同时，了解您可以针对自定义实现调整其中一些值也是件好事。您通常会希望调整 proxy_buffers 和 proxy_buffer_size 指令。

下面是一个增加每个上游请求可用代理缓冲区数量的示例。它在减少存储标头的缓冲区大小的同时实现了这一点：

让我们看看如何通过完全关闭缓冲来更快地向快速客户端提供数据。如果您的客户端不够快，Nginx 将自动使用缓冲区。但是，它会首先将数据刷新到客户端，而不是等待缓冲池。这种配置有一个缺点。这种配置会导致慢速客户端的上游服务器连接保持打开状态，直到客户端接收到所有响应数据。如果缓冲设置为“off”，则仅使用由 proxy_buffer_size 指令定义的缓冲区。以下是显示如何指定关闭缓冲的代码片段：

• 配置高可用性 (HA) 基础设施（可选设置）

您可以在 Nginx 代理配置中添加一组冗余的负载均衡器，以确保其更加健壮，从而实现高可用性。高可用性 (HA) 架构是一种没有单点故障的基础设施。负载均衡器是此配置的一部分。通过使用多个负载均衡器，您可以防止在某个负载均衡器发生故障或因维护而离线时出现潜在的停机时间。

如何实现 Nginx 代理缓存以缩短响应时间

在上一节中，我们讨论了如何使用缓冲区来释放后端服务器以处理更多请求。Nginx 还提供了另一个功能，允许我们缓存来自后端的响应数据。它完全免去了为所有传入请求连接上游服务器的需要。

实现代理缓存

proxy_cache_path 指令允许我们通过指定用于存储代理内容的磁盘区域来设置缓存。proxy_cache_path 指令在 http 上下文中进行定义。

以下配置代码片段是如何实现缓存系统的示例：

在此代码片段中，我们使用了 proxy_cache_path 指令来定义文件系统上保存缓存的目录。在本例中，我们设置的目录是 /var/lib/nginx/cache。您可以自由定义自己选择的目录路径。使用以下命令创建您选择的目录，并设置正确的权限和所有权：

在代码片段中，levels= 参数指定了缓存的组织结构。Nginx 将通过对键的值（使用 proxy_cache_key 指令指定）进行哈希处理来创建缓存键。我们指定的 levels (1:2) 表示将创建一个单字符目录（即哈希值的最后一个字符）以及一个双字符子目录（取自哈希值倒数第二和第三个字符）。在大多数情况下，您无需关心这一点。然而，了解它如何帮助 Nginx 快速找到相关值是有好处的。

keys_zone= 参数定义了缓存区域的名称，在我们的示例中，我们将其命名为 backendcache。在这里，我们还定义了想要存储多少元数据。在此示例中，我们存储了 8 MB 的键。Nginx 每兆字节大约可以存储 8000 个条目。max_size 参数指定了实际缓存数据的最大大小，在我们的示例中为 50MB。

您还应该注意所使用的 proxy_cache_key 指令。该指令指定了我们将用于存储缓存值的键。我们将使用相同的键来检查请求是否存在于缓存中。我们已将该键指定为 scheme（http 或 https）、HTTP 请求方法以及请求的主机和 URI 的组合。

此外，我们还使用了 proxy_cache_valid 指令。可以针对各种状态码多次指定该指令。它允许我们根据状态码指定存储值的时间。在代码片段中，我们为成功状态码指定了 10 分钟，为 404 响应指定了 1 分钟。

既然我们已经配置了缓存区域，下一步就是通过告诉 Nginx 何时使用缓存来使配置生效。以下是一个配置片段，展示了我们如何实现该缓存的使用：

在 proxy_cache 指令中，我们指定了该上下文应使用 backendcache 缓存区。如果您在缓存配置中选择了其他名称，可以在此处进行替换。对于每个有效的条目，Nginx 会在将请求传递给后端上游服务器之前检查缓存。

我们定义了 proxy_cache_bypass 指令以使用 $http_cache_control 变量。该变量告诉服务器是应该返回缓存的响应，还是返回资源的新鲜且未缓存的版本。合理设置此指令可以让 Nginx 正确处理来自客户端的各种类型的传入请求。

还指定了一个名为 X-Proxy-Cache 的附加标头。该标头的值为 $upstream_cache_status 变量。它向我们提供有关请求是导致缓存命中、缓存未命中还是显式绕过缓存的信息。此类信息对客户端非常有用，并且在应用程序调试期间至关重要。

关于缓存结果的重要注意事项

虽然缓存将大大提高代理服务器的性能，但在实现缓存时应注意以下几点：

任何与用户’个人信息相关的数据都不应该被缓存，以避免一个用户的数据对另一个用户可见的情况。

您的后端服务器应该考虑您网站的所有动态元素。我们可以在响应中指定几个 Cache-Control 标头以达到不同的目的。让我们来讨论它们：

• no-cache – 指定代理在提供响应之前必须检查后端的数据是否已更改。这适用于动态和重要的数据。每次请求都会检查 ETag 哈希元数据标头，如果后端返回相同的哈希值，则提供之前的值。

• no-store – 指定不对接收到的任何数据进行缓存，因此，每个请求都将转到服务器以获取新鲜数据。这对于敏感数据是最安全的。

• private – 指定任何共享缓存空间都不应缓存该数据。您可以使用此标头指定在用户的浏览器中进行缓存，但同时也通知代理服务器将该数据视为对后续请求无效。

• public – 指定公共响应，并允许在连接中的任何位置进行缓存。

您可以使用 max-age 标头指定您希望缓存持续的时间（以秒为单位）。上面定义的各种标头可以帮助您实现缓存，同时确保敏感数据的安全、动态数据的新鲜，最重要的是，提高您服务器’的性能。

如果您的后端服务器运行的是 Nginx 服务器，您可以在 server 块中指定缓存的有效时间。您可以通过在配置中添加 expires 指令来实现此目的，如下所示：

第一个块允许将内容缓存 59 分钟，而第二个块表示不进行缓存。这些设置适用于 Cache-Control 标头选项，例如，第二个块为 “no-cache”。

您可以使用 add-header 指令来设置其他值：

结论

在本教程中，我们了解了 Nginx 的强大功能。Nginx 既是一个 Web 服务器，最重要的是，它还是一个反向代理。Nginx 的设计使其能够处理数千个并发连接。这使其非常适合负载均衡。由于这种设计，将请求代理到其他后端服务器进行处理是非常简单直接的。

凭借本教程中的知识，得益于 Nginx 的灵活性，您应该能够实现复杂的代理和负载均衡器。

这里有一些资源，您可以在我们的博客上找到，以帮助您进一步了解 Nginx：

• 如何在 Ubuntu 20.04 上使用 Let’s Encrypt 保护 Nginx 安全

• 如何在 Ubuntu 20.04 上安装 LEMP 栈（Linux、Nginx、MySQL、PHP）

• Web 服务器的世界：Apache vs. Nginx

• 使用 Docker Compose 部署 Laravel、Nginx 和 MySQL

祝您使用愉快！