Nginx负载均衡配置–简介

在使用tomcat部署静态网站的时候，由于服务器比较垃圾，所以如果多人同时访问的话，可能会造成卡顿，影响用户体验。所以想到了使用负载均衡。

1. 什么是负载均衡

负载平衡是高可用性基础架构的关键组件，通常用于通过在多个服务器之间分配工作负载来提高网站，应用程序，数据库和其他服务的性能和可靠性。

没有负载平衡的Web基础结构可能如下所示：

在此示例中，用户直接连接到web服务器yourdomain.com。如果此单个Web服务器出现故障，用户将无法再访问该网站。此外，如果许多用户尝试同时访问服务器并且无法处理负载，则可能会遇到加载时间缓慢或根本无法连接的情况。

通过在后端引入负载均衡器和至少一个额外的Web服务器，可以减轻此单点故障。通常，所有后端服务器都将提供相同的内容，以便用户无论哪个服务器响应都会收到一致的内容。

在上面说明的示例中，用户访问负载均衡器，负载均衡器将用户的请求转发到后端服务器，后端服务器然后直接响应用户的请求。在这种情况下，单点故障现在是负载平衡器本身。这可以通过引入第二个负载均衡器来缓解.

2. 负载均衡器可以处理什么样的流量

  • HTTP - 标准HTTP平衡基于标准HTTP机制定向请求。负载均衡器设置X-Forwarded-For，X-Forwarded-Proto以及X-Forwarded-Port头，提供有关原始请求的后端信息。

  • HTTPS - HTTPS平衡功能与HTTP平衡功能相同，但增加了加密功能。加密以两种方式之一处理：使用SSL直通，一直保持加密到后端，或者使用SSL终止，将解密负担放在负载均衡器上，但将未加密的流量发送到后端。

  • TCP - 对于不使用HTTP或HTTPS的应用程序，也可以平衡TCP流量。例如，数据库集群的流量可以分布在所有服务器上。

  • UDP–最近，一些负载均衡器增加了对使用UDP的核心互联网协议（如DNS和syslogd）的负载平衡的支持。

这些转发规则将定义负载均衡器本身的协议和端口，并将它们映射到负载均衡器将用于将流量路由到后端的协议和端口。

3. 负载均衡器如何选择后端服务器

负载均衡器根据两个因素的组合选择将请求转发到哪个服务器。他们将首先确保他们可以选择的任何服务器实际上对请求做出适当的响应，然后使用预先配置的规则从该健康池中进行选择。

3.1 健康检查

负载均衡器应仅将流量转发到“健康”的后端服务器。要监视后端服务器的运行状况，运行状况检查会定期尝试使用转发规则定义的协议和端口连接到后端服务器，以确保服务器正在侦听。如果服务器未通过运行状况检查，因此无法提供请求，则会自动将其从池中删除，并且在再次响应运行状况检查之前，流量将不会转发给它。

3.2 负载平衡算法

使用的负载平衡算法确定将选择后端中的哪些正常服务器。一些常用的算法是：

  • Round Robin - Round Robin意味着将按顺序选择服务器。负载均衡器将在其列表中为第一个请求选择第一个服务器，然后按顺序向下移动列表，当它到达结尾时从顶部开始。

  • least_conn - least_conn意味着负载均衡器将选择连接最少的服务器，并且当流量导致更长的会话时建议使用。

  • ip_hash：此平衡算法根据客户端的IP地址将请求分发到不同的服务器。前三个八位字节用作决定服务器处理请求的密钥。结果是客户端每次都倾向于由同一服务器提供服务，这有助于会话一致性。

  • hash：此平衡算法主要用于memcached代理。基于任意提供的散列密钥的值来划分服务器。这可以是文本，变量或组合。这是唯一需要用户提供数据的平衡方法，这是应该用于哈希的密钥。

管理员可用的算法取决于所使用的特定负载平衡技术。

3.3 负载平衡器如何处理状态

某些应用程序要求用户继续连接到同一后端服务器。Source算法根据客户端IP信息创建关联。在Web应用程序级别实现此目的的另一种方法是通过粘性会话，其中负载平衡器设置cookie，并且来自该会话的所有请求都定向到同一物理服务器。

4. 冗余负载均衡器

要将负载均衡器作为单点故障移除，可以将第二个负载均衡器连接到第一个负载均衡器以形成一个集群，其中每个负载均衡器监控其他负载平衡器的运行状况。每个人都具有同样的故障检测和恢复能力。

如果主负载均衡器发生故障，DNS必须将用户带到第二个负载均衡器。由于DNS更改可能需要花费大量时间在Internet上传播并自动进行此故障转移，因此许多管理员将使用允许灵活IP地址重新映射的系统，例如浮动IP。按需IP地址重新映射通过提供可在需要时轻松重新映射的静态IP地址，消除了DNS更改中固有的传播和缓存问题。域名可以保持与相同的IP地址关联，而IP地址本身在服务器之间移动。

这就是使用浮动IP的高可用性基础架构的外观：

使用

1. 一般代理信息

如果您过去仅使用Web服务器进行简单的单服务器配置，您可能想知道为什么需要代理请求。

从Nginx代理其他服务器的一个原因是能够扩展您的基础架构。构建Nginx是为了同时处理许多并发连接。这使其成为客户联系点的理想选择。服务器可以将请求传递给任意数量的后端服务器，以处理大部分工作，从而在整个基础架构中分散负载。此设计还为您提供了轻松添加后端服务器或根据维护需要将其下载的灵活性。

http代理可能有用的另一个实例是使用可能无法构建的应用程序服务器来直接处理来自生产环境中的客户端的请求。许多框架都包含Web服务器，但大多数框架都不如Nginx等高性能服务器那么强大。将Nginx放在这些服务器之前可以为用户带来更好的体验并提高安全性。

在Nginx中代理是通过操纵针对Nginx服务器的请求并将其传递给其他服务器以进行实际处理来完成的。请求的结果将传递回Nginx，然后Nginx将信息中继到客户端。此实例中的其他服务器可以是远程计算机，本地服务器，甚至是Nginx中定义的其他虚拟服务器。Nginx代理请求的服务器称为上游服务器。

Nginx可以将请求代理到使用http（s），FastCGI，SCGI和uwsgi或memcached协议通过每种代理类型的单独指令集进行通信的服务器。在本指南中，我们将重点关注http协议。Nginx实例负责传递请求并将任何消息组件按摩成上游服务器可以理解的格式。

2. 解构基本HTTP代理通行证

最直接的代理类型涉及将请求切换到可以使用http进行通信的单个服务器。这种类型的代理称为通用“代理传递”，由适当命名的proxy_pass指令处理。

该proxy_pass指令主要在位置上下文中找到。它if在位置上下文和limit_except上下文中的块中也是有效的。当请求与具有proxy_pass指令的位置匹配时，请求将转发到指令给出的URL。

我们来看一个例子：

# server context

location /match/here {
    proxy_pass http://example.com;
}

. . .

在上面的配置代码段中，proxy_pass定义中服务器末尾没有给出URI 。对于符合此模式的定义，客户端请求的URI将按原样传递到上游服务器。

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

我们来看看替代方案：

# server context

location /match/here {
    proxy_pass http://example.com/new/prefix;
}

. . .

在上面的示例中，代理服务器在end（/new/prefix）上定义了一个URI段。当在proxy_pass定义中给出URI时，在传递期间，请求的与位置定义匹配的部分将被此URI替换。

例如，/match/here/pleaseNginx服务器上的请求将作为传递给上游服务器http://example.com/new/prefix/please 该/match/here所取代/new/prefix。这是一个要记住的重点。

有时，这种替换是不可能的。在这些情况下，将proxy_pass忽略定义末尾的URI，并且客户端的原始URI或其他指令修改的URI将传递给上游服务器。

例如，当使用正则表达式匹配位置时，Nginx无法确定URI的哪个部分与表达式匹配，因此它发送原始客户端请求URI。另一个例子是在同一位置使用重写指令时，导致客户端URI被重写，但仍然在同一个块中处理。在这种情况下，将传递重写的URI。

3. 了解Nginx如何处理Headers

有一点可能不会立即明确的是，如果您希望上游服务器正确处理请求，则传递的不仅仅是URI。代表客户端来自Nginx的请求与直接来自客户端的请求看起来不同。其中很大一部分是与请求一起出现的标头。

当Nginx代理请求时，它会自动对从客户端收到的请求标头进行一些调整：

Nginx摆脱任何空头。没有必要将空值传递给另一台服务器; 它只会使请求膨胀。 默认情况下，Nginx会将包含下划线的任何标头视为无效。它将从代理请求中删除它们。如果你希望Nginx将这些解释为有效，你可以将underscores_in_headers指令设置为“on”，否则你的标题永远不会进入后端服务器。 “Host”头被重写为$proxy_host 变量定义的值。这将是上游的IP地址或名称和端口号，直接由proxy_pass指令定义。 “连接”标题更改为“关闭”。该标头用于表示关于双方之间建立的特定连接的信息。在这种情况下，Nginx将其设置为“关闭”以向上游服务器指示一旦原始请求被响应，该连接将被关闭。上游不应期望这种连接是持久的。 我们可以从上面推断的第一点是，您不希望传递的任何头应该设置为空字符串。具有空值的标头将从传递的请求中完全删除。

从上述信息中收集的下一个要点是，如果您的后端应用程序将处理非标准标头，则必须确保它们没有下划线。如果需要使用下划线的标头，可以underscores_in_headers在配置中将指令设置为“on”（在http上下文或IP地址/端口组合的默认服务器声明的上下文中有效）。如果不这样做，Nginx会将这些标头标记为无效，并在传递给您的上游之前静默删除它们。

“主机”标头在大多数代理方案中特别重要。如上所述，默认情况下，这将设置为$proxy_host 一个变量的值，该变量将包含直接从proxy_pass定义中获取的域名或IP地址和端口。这是默认情况下选择的，因为它是Nginx可以确定上游服务器响应的唯一地址（因为它是直接从连接信息中提取的）。

“Host”标头的最常见值如下：

  • $proxy_host：这将“主机”标头设置为从proxy_pass定义中获取的域名或IP地址和端口组合。从Nginx的角度来看，这是默认的“安全”，但通常不是代理服务器正确处理请求所需要的。

  • $http_host： 将“Host”标头设置为客户端请求的“Host”标头。客户端发送的标头始终在Nginx中作为变量提供。变量将以$http_前缀开头，后跟小写的标题名称，任何短划线都用下划线替换。尽管$http_host变量在大多数情况下都有效，但是当客户端请求没有有效的“主机”标头时，这可能会导致传递失败。

  • $host：此变量按优先顺序设置：请求行本身的主机名，客户端请求的“主机”标头或与请求匹配的服务器名称。

在大多数情况下，您需要将“Host”标头设置为$host变量。它是最灵活的，通常会为代理服务器提供尽可能准确填写的“主机”标头

4. 设置或重置标题

要调整或设置代理连接的标头，我们可以使用该proxy_set_header指令。例如，要像我们讨论的那样更改“Host”标头，并添加一些与代理请求相同的其他标头，我们可以使用以下内容：

# server context

location /match/here {
    proxy_set_header HOST $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    proxy_pass http://example.com/new/prefix;
}

. . .

上述请求将“Host”标头设置为$host变量，该变量应包含有关所请求的原始主机的信息的X-Forwarded-Proto报头给出了关于原始客户机请求的架构中的代理的服务器信息（它是否是一个HTTP或HTTPS请求）。

将X-Real-IP其设置为客户端的IP地址，以便代理可以根据此信息正确地做出决策或记录。该X-Forwarded-For标题是包含每一个客户端已通过代理到这一点的服务器的IP地址的列表。在上面的例子中，我们将其设置为$proxy_add_x_forwarded_for变量。此变量X-Forwarded-For获取从客户端检索的原始标头的值，并将Nginx服务器的IP地址添加到结尾。

当然，我们可以将proxy_set_header指令移到服务器或http上下文中，允许它在多个位置引用：

# server context

proxy_set_header HOST $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

location /match/here {
    proxy_pass http://example.com/new/prefix;
}

location /different/match {
    proxy_pass http://example.com;
}

5. 为负载平衡代理连接定义上游上下文

在前面的示例中，我们演示了如何对单个后端服务器执行简单的http代理。Nginx允许我们通过指定可以传递请求的整个后端服务器池来轻松扩展此配置。

我们可以通过使用该upstream指令来定义服务器池来实现此目的。此配置假定所列出的任何一个服务器都能够处理客户端的请求。这使我们可以毫不费力地扩展我们的基础设施。upstream必须在Nginx配置的http上下文中设置该指令。

我们来看一个简单的例子：

# http context

upstream backend_hosts {
    server host1.example.com;
    server host2.example.com;
    server host3.example.com;
}

server {
    listen 80;
    server_name example.com;

    location /proxy-me {
        proxy_pass http://backend_hosts;
    }
}

在上面的例子中，我们设置了一个名为的上游上下文backend_hosts。一旦定义，此名称将可用于代理传递，就像它是常规域名一样。如您所见，在我们的服务器块中，我们将任何请求传递example.com/proxy-me/…给我们上面定义的池。在该池中，通过应用可配置算法来选择主机。默认情况下，这只是一个简单的循环选择过程（每个请求将依次路由到不同的主机）。

5.1 改变上游平衡算法

您可以通过在上游上下文中包含指令或标志来修改上游池使用的平衡算法：

（循环法）：如果不存在其他平衡指令，则使用默认的负载平衡算法。在上游上下文中定义的每个服务器依次顺序传递请求。 least_conn：指定应始终为具有最少活动连接数的后端提供新连接。在与后端的连接可能持续一段时间的情况下，这尤其有用。 ip_hash：此平衡算法根据客户端的IP地址将请求分发到不同的服务器。前三个八位字节用作决定服务器处理请求的密钥。结果是客户端每次都倾向于由同一服务器提供服务，这有助于会话一致性。 hash：此平衡算法主要用于memcached代理。基于任意提供的散列密钥的值来划分服务器。这可以是文本，变量或组合。这是唯一需要用户提供数据的平衡方法，这是应该用于哈希的密钥。 更改平衡算法时，块可能如下所示：

# http context

upstream backend_hosts {

    least_conn;

    server host1.example.com;
    server host2.example.com;
    server host3.example.com;
}

. . .

在上面的示例中，将根据哪个连接最少来选择服务器。该ip_hash指令可以以相同的方式设置以获得一定量的会话“粘性”。

至于hash方法，您必须提供哈希的密钥。这可以是你想要的任何东西：

# http context

upstream backend_hosts {

    hash $remote_addr$remote_port consistent;

    server host1.example.com;
    server host2.example.com;
    server host3.example.com;
}

. . .

上面的示例将根据客户端IP地址和端口的值分发请求。我们还添加了可选参数consistent，该参数实现了ketama一致性哈希算法。基本上，这意味着如果您的上游服务器发生更改，则对缓存的影响最小。

5.2 设置服务器权重以进行平衡

在后端服务器的声明中，默认情况下，每个服务器都是“加权”的。这假设每个服务器可以并且应该处理相同的负载量（考虑到平衡算法的影响）。但是，您还可以在声明期间为服务器设置替代权重：

# http context

upstream backend_hosts {
    server host1.example.com weight=3;
    server host2.example.com;
    server host3.example.com;
}

. . .

在上面的例子中，host1.example.com将接收三倍于其他两个服务器的流量。默认情况下，为每个服务器分配权重1。

6. 使用缓冲区释放后端服务器

涉及许多用户的代理问题是向流程添加其他服务器对性能的影响。在大多数情况下，利用Nginx的缓冲和缓存功能可以大大减轻这种影响。

代理到另一台服务器时，两个不同连接的速度将影响客户端的体验：

从客户端到Nginx代理的连接。 从Nginx代理到后端服务器的连接。 Nginx能够根据您希望优化的这些连接中的任何一个来调整其行为。

没有缓冲区，数据从代理服务器发送并立即开始传输到客户端。如果假设客户端速度很快，则可以关闭缓冲，以便尽快将数据传送到客户端。使用缓冲区，Nginx代理将临时存储后端的响应，然后将此数据提供给客户端。如果客户端很慢，这允许Nginx服务器更快地关闭到后端的连接。然后，它可以处理以任何可能的速度将数据分发给客户端。

Nginx默认采用缓冲设计，因为客户端的连接速度往往差异很大。我们可以使用以下指令调整缓冲行为。这些可以在http，服务器或位置上下文中设置。重要的是要记住，每个请求都配置了大小调整指令，因此当有许多客户端请求时，增加它们超出您的需要会影响您的性能：

proxy_buffering：此指令控制是否启用此上下文和子上下文的缓冲。默认情况下，这是“打开”。 proxy_buffers：此指令控制代理响应的缓冲区的数量（第一个参数）和大小（第二个参数）。默认设置是配置8个大小等于一个内存页面的缓冲区（4k或者8k）。增加缓冲区数量可以让您缓冲更多信息。 proxy_buffer_size：来自后端服务器的响应的初始部分（包含标头）与响应的其余部分分开缓冲。该指令设置响应的这一部分的缓冲区大小。默认情况下，这与大小相同proxy_buffers，但由于这用于标题信息，因此通常可以将其设置为较低的值。 proxy_busy_buffers_size：此指令设置可以标记为“客户端就绪”并因此忙碌的缓冲区的最大大小。虽然客户端一次只能从一个缓冲区读取数据，但缓冲区放在队列中以便以串联形式发送到客户端。该指令控制允许处于此状态的缓冲区空间的大小。 proxy_max_temp_file_size：这是磁盘上临时文件的每个请求的最大大小。这些是在上游响应太大而无法放入缓冲区时创建的。 proxy_temp_file_write_size：这是当代理服务器的响应对于配置的缓冲区而言太大时，Nginx将一次写入临时文件的数据量。 proxy_temp_path：这是磁盘上区域的路径，当上游服务器的响应无法容纳到配置的缓冲区时，Nginx应该存储任何临时文件。 如您所见，Nginx提供了许多不同的指令来调整缓冲行为。大多数情况下，您不必担心大多数这些，但调整其中一些值可能很有用。调整最有用的可能是proxy_buffers和proxy_buffer_size指令。

增加每个上游请求的可用代理缓冲区数量的示例，同时减少可能存储标头的缓冲区将如下所示：

# server context

proxy_buffering on;
proxy_buffer_size 1k;
proxy_buffers 24 4k;
proxy_busy_buffers_size 8k;
proxy_max_temp_file_size 2048m;
proxy_temp_file_write_size 32k;

location / {
    proxy_pass http://example.com;
}

相反，如果您想要立即向其提供数据的快速客户端，则可以完全关闭缓冲。如果上游比客户端更快，Nginx实际上仍将使用缓冲区，但它会立即尝试将数据刷新到客户端，而不是等待缓冲区池。如果客户端速度很慢，这可能导致上游连接保持打开状态，直到客户端赶上。当缓冲“关闭”时，仅proxy_buffer_size使用指令定义的缓冲区：

# server context

proxy_buffering off;
proxy_buffer_size 4k;

location / {
    proxy_pass http://example.com;
}

6.1 高可用性（可选）

通过添加一组冗余的负载均衡器，可以使Nginx代理更加健壮，从而创建高可用性基础架构。

甲高可用性（HA）的设置是无故障的单个点处的基础设施，和你的负载平衡器是该构造的一部分。通过使用多个负载均衡器，可以防止在负载均衡器不可用或需要将其关闭进行维护时可能导致的停机。

以下是基本高可用性设置的图表：

在此示例中，您有一个静态IP地址后面的多个负载平衡器（一个活动和一个或多个被动），可以从一个服务器重新映射到另一个服务器。客户端请求从静态IP路由到活动负载平衡器，然后路由到后端服务器。要了解更多信息，请阅读如何使用浮动IP的这一节。

7. 配置代理缓存以减少响应时间

虽然缓冲可以帮助释放后端服务器以处理更多请求，但Nginx还提供了一种从后端服务器缓存内容的方法，从而无需为许多请求连接到上游。

7.1 配置代理缓存

要设置用于代理内容的缓存，我们可以使用该proxy_cache_path指令。这将创建一个区域，可以保留从代理服务器返回的数据。该proxy_cache_path指令必须在http上下文中设置。

在下面的示例中，我们将配置此命令和一些相关指令来设置我们的缓存系统。

# http context

proxy_cache_path /var/lib/nginx/cache levels=1:2 keys_zone=backcache:8m max_size=50m;
proxy_cache_key "$scheme$request_method$host$request_uri$is_args$args";
proxy_cache_valid 200 302 10m;
proxy_cache_valid 404 1m;

使用该proxy_cache_path指令，我们已经在文件系统上定义了一个目录，我们希望存储缓存。在这个例子中，我们选择了/var/lib/nginx/cache目录。如果此目录不存在，您可以通过键入以下内容以正确的权限和所有权创建它：

sudo mkdir -p /var/lib/nginx/cache
sudo chown www-data /var/lib/nginx/cache
sudo chmod 700 /var/lib/nginx/cache

该levels=参数指定缓存的组织方式。Nginx将通过散列键的值（下面配置）来创建缓存键。我们在上面选择的级别规定将创建一个单个字符目录（这将是散列值的最后一个字符），其中包含一个两个字符的子目录（取自散列值末尾的下两个字符）。您通常不必关心此细节，但它有助于Nginx快速找到相关值。

该keys_zone=参数定义了我们调用的此缓存区的名称backcache。这也是我们定义要存储多少元数据的地方。在这种情况下，我们存储8 MB的密钥。对于每兆字节，Nginx可以存储大约8000个条目。该max_size参数设置实际缓存数据的最大大小。

我们上面使用的另一个指令是proxy_cache_key。这用于设置将用于存储缓存值的键。该相同密钥用于检查是否可以从缓存提供请求。我们将此设置为方案（http或https），HTTP请求方法以及请求的主机和URI的组合。

该proxy_cache_valid指令可以多次指定。它允许我们根据状态代码配置存储值的时间长度。在我们的示例中，我们存储成功和重定向10分钟，并且每分钟使缓存过期404响应。

现在，我们已经配置了缓存区域，但我们仍然需要告诉Nginx何时使用缓存。

在我们代理后端的位置，我们可以配置此缓存的使用：

# server context

location /proxy-me {
    proxy_cache backcache;
    proxy_cache_bypass $http_cache_control;
    add_header X-Proxy-Cache $upstream_cache_status;

    proxy_pass http://backend;
}

. . .

使用该proxy_cache指令，我们可以指定backcache缓存区域应该用于此上下文。在传递到后端之前，Nginx将在此处检查有效条目。

该proxy_cache_bypass指令设置为$http_cache_control 变量。这将包含一个指示器，指示客户端是否明确请求资源的新的非缓存版本。设置此指令允许Nginx正确处理这些类型的客户端请求。无需进一步配置。

我们还添加了一个名为的额外标题X-Proxy-Cache。我们将此标头设置为$upstream_cache_status变量的值。基本上，这会设置一个标头，允许我们查看请求是否导致缓存命中，缓存未命中，或者是否明确绕过了缓存。这对于调试尤其有用，但对于客户端也是有用的信息。

7.2 有关缓存结果的说明

缓存可以极大地提高代理的性能。但是，配置缓存时必须牢记一些注意事项。

首先，任何用户相关的数据应该不会被缓存。这可能导致一个用户的数据被呈现给另一个用户。如果您的网站完全是静态的，这可能不是问题。

如果您的站点有一些动态元素，则必须在后端服务器中对此进行说明。如何处理这取决于处理后端处理的应用程序或服务器。对于私有内容，您应将Cache-Control标头设置为no-cache，no-store或private，具体取决于数据的性质： no-cache：表示如果没有先检查后端的数据是否未更改，则不应再次提供响应。如果数据是动态且重要的，则可以使用此方法。在每个请求上检查ETag散列元数据头，并且如果后端返回相同的散列值，则可以提供先前的值

no-store ：表示在任何时候都不应该缓存接收到的数据。这是私有数据最安全的选项，因为这意味着每次都必须从服务器检索数据。

private：这表示没有共享缓存空间应该缓存此数据。这可用于指示用户的浏览器可以缓存数据，但代理服务器不应认为此数据对后续请求有效。

public：这表示响应是可以在连接中的任何位置缓存的公共数据。

可以控制此行为的相关标头是max-age标头，它指示应缓存任何资源的秒数。

正确设置这些标题（取决于内容的敏感性）将有助于您利用缓存，同时保护您的私人数据安全并使您的动态数据保持新鲜。

如果你的后端也使用Nginx，你可以使用expires指令设置一些，这将设置max-age为Cache-Control：


location / {
    expires 60m;
}

location /check-me {
    expires -1;
}

在上面的示例中，第一个块允许将内容缓存一小时。第二个块将Cache-Control标头设置为“no-cache”。要设置其他值，可以使用该add_header指令，如下所示：

location /private {
    expires -1;
    add_header Cache-Control "no-store";
}

8. 结论

Nginx首先是一个反向代理，它也恰好具有作为Web服务器工作的能力。由于此设计决策，向其他服务器代理请求非常简单。Nginx非常灵活，如果需要，可以对代理配置进行更复杂的控制

原文地址

参考