浏览 2.2k
原文作者:Timo Stark of F5 和 Sergey Budnevich of F5
原文链接:避免 10 大 NGINX 配置错误
转载来源:NGINX 官方网站
在帮助 NGINX 用户解决问题时,我们经常会发现配置错误,这种配置错误也屡屡出现在其他用户的配置中,甚至有时还会出现在我们的 NGINX 工程师同事编写的配置中!本文介绍了 10 个最常见的错误,并解释了问题所在以及相应的解决方法。由于本文篇幅较长,我们将分上下两篇发布。
worker_connections
指令用于设置 NGINX worker 进程可以打开的最大并发连接数(默认为 512)。所有类型的连接(例如与代理服务器的连接)都计入最大值,而不仅仅是客户端连接。但重要的是要记住,最终每个 worker 的并发连接数还有另一个限制:操作系统对分配给每个进程的文件描述符 (file descriptor,即FD) 最大数量的限制。在现代 UNIX 发行版中,默认限制为 1024。
对于除最小的NGINX部署之外的 所有部署,将每个 worker 的连接数限制为 512 可能太少了。事实上,我们将随 NGINX 开源版二进制文件和 NGINX Plus 一起分发的默认 nginx.conf 文件将其增加到 1024。
常见的配置错误是没有将 FD 的限制增加到至少两倍的 worker_connections
的值。解决方法是在主配置上下文中使用 worker_rlimit_nofile
指令设置该值。
这就是需要更多 FD 的原因:从 NGINX worker 进程到客户端或上游服务器的每个连接都消耗一个 FD。当 NGINX 充当 Web 服务器时,每个客户端连接使用一个 FD,每个服务的文件使用一个 FD,这样每个客户端至少需两个 FD(但大多数网页是由许多文件构建的)。当充当代理服务器时,NGINX 分别使用一个 FD 连接客户端和上游服务器,并可能用到第三个 FD 给用于临时存储服务器响应的文件。作为缓存服务器时,NGINX 的行为类似于缓存响应的 Web 服务器,如果缓存为空或过期,则类似于代理服务器。
NGINX 为每个日志文件使用一个 FD,并会用几个 FD 与主进程通信,但与用于连接和文件的 FD 数量相比,这些数量通常很少。
UNIX 提供了几种方法来设置每个进程的 FD 数量:
ulimit
命令init
脚本或 systemd
服务清单变量使用的方法取决于您如何启动 NGINX,而 worker_rlimit_nofile
与您启动 NGINX 的方式无关。
FD 的数量也有系统范围的限制,您可以使用操作系统的 sysctl
fs.file-max
命令进行设置。它通常足够大,但有必要验证所有 NGINX worker 进程可能使用的文件描述符的最大数量 (worker_rlimit_nofile
*
worker_processes
) 明显小于 fs.file‑max
。如果 NGINX 以某种方式使用了所有可用的 FD(例如,在 DoS 攻击期间),此时甚至都无法登录机器来解决问题。
error_log
off
指令常见的错误是认为 error_log
off
指令会禁用日志记录。事实上,与 access_log
指令不同,error_log
不包含 off
参数。如果在配置中添加了 error_log
off
指令,则 NGINX 会在 NGINX 配置文件的默认目录(通常是/etc/nginx)中创建一个名为 off 的错误日志文件。
我们不建议禁用错误日志,因为它是调试 NGINX 任何问题时的重要信息来源。但是,如果存储空间非常有限,记录的数据可能足以耗尽可用的磁盘空间,此时禁用错误日志记录可能有意义。在主配置上下文中包含该指令:
error_log /dev/null emerg;
请注意,在 NGINX 读取并验证配置之前,该指令不会应用。因此,每次 NGINX 启动或重新加载配置时,它可能会记录到默认的错误日志位置(通常为/var/log/nginx/error.log),直到配置验证后。更改日志目录的方法是,在 nginx
命令中添加 -e
<error_log_location>
参数。
默认情况下,NGINX 会为每个新的传入请求打开一个到上游(后端)服务器的新连接。这种操作虽然安全但是低效,因为 NGINX 和服务器必须交换三个数据包来建立连接,并交换三个或四个数据包来终止连接。
在流量高峰期,为每个请求打开一个新连接会耗尽系统资源,最终导致根本无法打开连接。原因是:对于每个连接,源地址、源端口、目标地址和目标端口的4元组必须是唯一的。对于从 NGINX 到上游服务器的连接,四元组中的三个(第一个、第三个和第四个)是固定的,只有源端口是变量。当连接关闭时,Linux 套接字会处于 TIME‑WAIT
状态两分钟,在流量高峰期时这会增加可用源端口池耗尽的可能性。如果发生这种情况,NGINX 将无法打开与上游服务器的新连接。
解决方法是在 NGINX 和上游服务器之间启用 keepalive 连接 —— 该连接不会在请求完成时关闭,而是保持打开状态以用于其他请求。这样做既降低了源端口耗尽的可能性,又提高了性能。
启用 keepalive 连接的方法是:
NGINX 指令是向下继承的,或者是“由外而内”继承的:一个子上下文(一个嵌套在另一个上下文,即父上下文中的上下文)继承父上下文包含的指令的设置。例如,http{}
上下文中的所有server{}
和 location{}
块都继承了包含在 http
级别的指令的值,并且 server{}
块中的指令被它的所有子 location{}
块继承。但是,当父上下文及其子上下文中包含相同的指令时,这些值不会相加 —— 相反,子上下文中的值会覆盖父上下文中的值。
常见的错误是忘记了这种数组指令的“覆盖规则”,它不仅可以包含在多个上下文中,而且还可以在给定上下文中包含多次。例如 proxy_set_header
和 add_header
—— 第二个名称中包含“add”导致覆盖规则很容易被忘记。
我们可以通过 add_header
的例子来说明继承的工作机制:
http { add_header X-HTTP-LEVEL-HEADER 1; add_header X-ANOTHER-HTTP-LEVEL-HEADER 1; server { listen 8080; location / { return 200 "OK"; } } server { listen 8081; add_header X-SERVER-LEVEL-HEADER 1; location / { return 200 "OK"; } location /test { add_header X-LOCATION-LEVEL-HEADER 1; return 200 "OK"; } location /correct { add_header X-HTTP-LEVEL-HEADER 1; add_header X-ANOTHER-HTTP-LEVEL-HEADER 1; add_header X-SERVER-LEVEL-HEADER 1; add_header X-LOCATION-LEVEL-HEADER 1; return 200 "OK"; } }}
对于监听端口 8080 的服务器,server{}
或 location{}
块中都没有 add_header
指令。所以继承很简单,我们看到 http{}
上下文中定义了下面两个http消息头:
% curl -is localhost:8080HTTP/1.1 200 OKServer: nginx/1.21.5Date: Mon, 21 Feb 2022 10:12:15 GMTContent-Type: text/plainContent-Length: 2Connection: keep-aliveX-HTTP-LEVEL-HEADER: 1X-ANOTHER-HTTP-LEVEL-HEADER: 1OK
对于监听端口 8081 的服务器,server{}
块中有一个 add_header
指令,但其子 location
/
块中没有该指令。server{}
块中定义的消息头覆盖了 http{}
上下文中定义的两个http消息头:
% curl -is localhost:8081HTTP/1.1 200 OKServer: nginx/1.21.5Date: Mon, 21 Feb 2022 10:12:20 GMTContent-Type: text/plainContent-Length: 2Connection: keep-aliveX-SERVER-LEVEL-HEADER: 1OK
在子 location
/test
块中,有一个 add_header
指令,该指令覆盖了其父 server{}
块中的http消息头和 http{}
上下文中的两个http消息头:
% curl -is localhost:8081/testHTTP/1.1 200 OKServer: nginx/1.21.5Date: Mon, 21 Feb 2022 10:12:25 GMTContent-Type: text/plainContent-Length: 2Connection: keep-aliveX-LOCATION-LEVEL-HEADER: 1OK
如果我们希望 location{}
块保留其父上下文中定义的http消息头以及本地定义的任何http消息头,我们必须在 location{}
块中重新定义父http消息头。这就是我们在 location
/correct
块中所做的:
% curl -is localhost:8081/correctHTTP/1.1 200 OKServer: nginx/1.21.5Date: Mon, 21 Feb 2022 10:12:30 GMTContent-Type: text/plainContent-Length: 2Connection: keep-aliveX-HTTP-LEVEL-HEADER: 1X-ANOTHER-HTTP-LEVEL-HEADER: 1X-SERVER-LEVEL-HEADER: 1X-LOCATION-LEVEL-HEADER: 1OK
proxy_buffering
off
指令NGINX 默认启用代理缓冲(proxy_buffering
指令设置为 on
)。代理缓冲意味着 NGINX 将来自服务器的响应存储在内部缓冲区中,并且在整个响应被缓冲之后才开始向客户端发送数据。缓冲有助于优化慢速客户端的性能 —— 因为 NGINX 缓冲响应的时间与客户端检索所有响应的时间一样长,代理服务器可以尽可能快地返回响应,然后返回到可用的状态以响应其他请求。
如果代理缓冲被禁用,则 NGINX 只会在默认为一个内存页大小(4 KB 或 8 KB,具体取决于操作系统)的缓冲区内缓存服务器响应的开头部分后就开始向客户端传输。通常,这个缓存空间只够缓存响应http消息头。NGINX 收到响应后会同步发送给客户端,迫使服务器处于空闲状态,直到 NGINX 可以接受下一个响应段为止。
因此,对于经常在 NGINX 配置中看到 proxy_buffering
off
指令的情况,我们感到非常惊讶。也许这样做是为了减少客户端延迟,但其影响可以忽略不计,而关闭后的副作用却很多:代理缓冲被禁用后,速率限制和缓存即便配置了也不起作用,性能也会受影响等等。
只有在少数情况下,禁用代理缓冲可能有意义(例如长轮询),因此我们强烈建议不要更改默认设置。有关更多信息,请参阅《NGINX Plus 管理指南》。
想要更及时全面地获取 NGINX 相关的技术干货、互动问答、系列课程、活动资源?
请前往 NGINX 开源社区:
按点赞数排序
按时间排序