分析：避免 10 大 NGINX 配置错误2023/7/3 9:51:22

huhaorong1984 · 发表于 2023-7-3 09:51:23

在帮助NGINX用户解决问题时，我们经常会发现配置错误，这种配置错误也屡屡出现在其他用户的配置中，甚至有时还会出现在我们的NGINX工程师同事编写的配置中！本文介绍了10个比较常见的错误，并解释了问题所在以及相应的解决方法。因此，这就是选择[url=http:///www.nginx-cn.net/blog/our-roadmap-quic-http-3-support-nginx/]HTTP/3 开发路线图[/url]的原因，不可否认其带来的积极影响。NGINX 已成为 F5, Inc 的一员，而 F5, Inc 则是当前全球热门的开源项目 NGINX 背后的公司。[align=center]https://www.nginx-cn.net/wp-content/uploads/2023/06/tutorial-deploy-configure-microservices_topology-01-1536x825.png[/align]

每个的文件描述符不足
_指令
未启用与上游服务器的连接
忘记指令继承的工作机制
_指令
指令使用不当
过多的健康检查
不安全地访问指标
当所有流量都来自同一个24CIDR块时使用_
不采用上游组

错误1：每个没有足够的文件描述符
_指令用于设置NGINX进程可以打开的比较大并发连接数（默认为512）。所有类型的连接（例如与代理服务器的连接）都计入比较大值，而不仅仅是客户端连接。但重要的是要记住，比较终每个的并发连接数还有另一个限制：操作系统对分配给每个进程的文件描述符(，即FD)比较大数量的限制。在现代UNIX发行版中，默认限制为1024。

对于除比较小的NGINX部署之外的所有部署，将每个的连接数限制为512可能太少了。事上，我们将随NGINX开源版二进制文件和NGINXP一起分发的默认文件将其增加到1024。

常见的配置错误是没有将FD的限制增加到至少两倍的_的值。解决方法是在主配置上下文中使用__指令设置该值。

这就是需要更多FD的原因：从NGINX进程到客户端或上游服务器的每个连接都消耗一个FD。当NGINX充当W服务器时，每个客户端连接使用一个FD，每个服务的文件使用一个FD，这样每个客户端至少需两个FD（但大多数页是由许多文件构建的）。当充当代理服务器时，NGINX分别使用一个FD连接客户端和上游服务器，并可能用到第个FD给用于临时存储服务器响应的文件。作为缓存服务器时，NGINX的行为类似于缓存响应的W服务器，如果缓存为空或过期，则类似于代理服务器。

NGINX为每个日志文件使用一个FD，并会用几个FD与主进程通信，但与用于连接和文件的FD数量相比，这些数量通常很少。

UNIX提供了几种方法来设置每个进程的FD数量：

如果从启动NGINX，则使用命令
如果将NGINX作为服务启动，则使用脚本或服务清单变量
文件

使用的方法取决于您如何启动NGINX，而__与您启动NGINX的方式关。

FD的数量也有系统范围的限制，您可以使用操作系统的-命令进行设置。它通常足够大，但有必要验证所有NGINX进程可能使用的文件描述符的比较大数量(__*_)明显小于?。如果NGINX以某种方式使用了所有可用的FD（例如，在DS攻击期间），此时甚至都法登录机器来解决问题。

错误2：_指令
常见的错误是认为_指令会禁用日志记录。事上，与_指令不同，_不包含参数。如果在配置中添加了_指令，则NGINX会在NGINX配置文件的默认目录（通常是）中创建一个为的错误日志文件。

我们不建议禁用错误日志，因为它是调试NGINX任何问题时的重要信息来源。但是，如果存储空间非常有限，记录的数据可能足以耗尽可用的磁盘空间，此时禁用错误日志记录可能有意义。在主配置上下文中包含该指令：

_;
请注意，在NGINX读取并验证配置之前，该指令不会应用。因此，每次NGINX启动或重新加载配置时，它可能会记录到默认的错误日志位置（通常为），直到配置验证后。更改日志目录的方法是，在命令中添加-__参数。

错误3：未启用与上游服务器的连接
默认情况下，NGINX会为每个新的传入请求打开一个到上游（后端）服务器的新连接。这种操作虽然安全但是低效，因为NGINX和服务器必须交换个数据包来建立连接，并交换个或四个数据包来终止连接。

在流量高峰期，为每个请求打开一个新连接会耗尽系统资源，比较终导致根本法打开连接。原因是：对于每个连接，源地址、源端口、目标地址和目标端口的4元组必须是仅有的。对于从NGINX到上游服务器的连接，四元组中的个（首个、第个和第四个）是固定的，只有源端口是变量。当连接关闭时，L套接字会处于TIME?WAIT状态两分钟，在流量高峰期时这会增加可用源端口池耗尽的可能性。如果发生这种情况，NGINX将法打开与上游服务器的新连接。

解决方法是在NGINX和上游服务器之间启用连接——该连接不会在请求完成时关闭，而是保持打开状态以用于其他请求。这样做既降低了源端口耗尽的可能性，又提高了性能。

启用连接的方法是：

在每个{}块中包含指令，以设置保存在每个进程缓存中的到上游服务器的空闲连接数。

请注意，指令不限制NGINX进程可以打开的上游服务器的连接总数——这一点经常被误解。所以的参数不需要像您想象的那么大。

我们建议将该参数设置为{}块中列出的服务器数量的两倍。这足以让NGINX保持与所有服务器的连接，同时也足够小，上游服务器还可以处理新的传入连接。

另请注意，当您在{}块中指定负载均衡算法时——使用、_、_、_或指令——该指令必须位于指令之前。通常，在NGINX配置中，指令顺序并不重要，而这是少数例外之一。

在将请求转发到上游的{}块中，添加以下指令以及_指令：

__11;
__"C""";
NGINX默认使用HTTP10连接上游服务器，并相应地将C:标头添加到它所转发到服务器的请求中。这样尽管{}块中包含了指令，但每个连接仍然会在请求完成时关闭。

__指令告知NGINX使用HTTP11，__指令将从C标头中删除值。

错误4：忘记指令继承的工作机制
NGINX指令是向下继承的，或者是“由外而内”继承的：一个子上下文（一个嵌套在另一个上下文，即父上下文中的上下文）继承父上下文包含的指令的设置。例如，{}上下文中的所有{}和{}块都继承了包含在级别的指令的值，并且{}块中的指令被它的所有子{}块继承。但是，当父上下文及其子上下文中包含相同的指令时，这些值不会相加——相反，子上下文中的值会覆盖父上下文中的值。

常见的错误是忘记了这种数组指令的“覆盖规则”，它不仅可以包含在多个上下文中，而且还可以在给定上下文中包含多次。例如__和_——第二个称中包含“”导致覆盖规则很容易被忘记。

		自动登录	找回密码
密码			立即注册