21

我正在设置一个 LEMP 堆栈来运行 Drupal。我安装了 Nginx 和 PHP-FastCGI。

Nginx 运行良好,但任何运行 PHP 的尝试都给了我错误“502 Bad Gateway”。

一个快速的谷歌发现:nginx 502 bad gateway,增加缓冲区大小解决了这个问题。

fastcgi_buffers 8 16k;
fastcgi_buffer_size 32k;

问题是为什么?

我的理解

从上一个链接来看,似乎 nginx 正在向 PHP-FastCGI 发送请求并且没有响应。这些请求超时了怎么办?

它没有足够的时间来响应,因为 php 很复杂(它不是,它是phpinfo();)。现在我已经增加了缓冲区,我什么时候应该担心必须再次增加缓冲区?

4

3 回答 3

14

如果您检查 nginx 错误日志,您很可能会看到以下消息:
upstream sent too big header while reading response header from upstream

fastcgi_buffers设置用于响应 FastCGI 上游的缓冲区段的数量和内存大小。

默认值,在文档中提供:
fastcgi_buffers 8 4k|8k;
默认缓冲区大小等于操作系统的 PAGESIZE。
getconf PAGESIZE允许获取当前内存页面大小。

例如,在 Ubuntu 14.01 中,默认 PAGESIZE 为 4KB。这意味着,您有 8 个段,每个段 4KB。总大小为 32KB。FastCGI 的响应超过这个数字,这就是为什么我们得到响应码的原因502 - server received

这不是很好的解释,但我希望它会帮助您更好地理解。

于 2015-11-09T07:04:41.860 回答
6

实际上,该问题仅与fastcgi_buffer_size. 这是一个非常特殊的缓冲区,它只保存来自响应的 HTTP 标头。

如果您的应用程序发出大量Set-Cookie标头(或其他有助于 HTTP 标头总大小的因素),则此处的默认缓冲区大小可能不够,您需要增加它。

要了解您需要如何增加它,您可以在这里阅读我的超级详细的文章 - 它是关于proxy_buffer_sizefastcgi_缓冲区的行为非常相似。引用基本命令:

curl -s -w \%{size_header} -o /dev/null https://example.com

-H如果需要,请确保针对正确的 URL 进行测试并通过添加请求标头。

这将为您提供以字节为单位的标头大小。然后,您需要将结果值与 4k(内存页的典型大小)对齐。

因此,如果您有,例如 14342 字节,则需要设置:

fastcgi_buffer_size 16k;

棘手的部分不存在,而是事实上当你增加这个缓冲区大小时,你需要增加一个fastcgi_buffer_size和/或fastcgi_busy_buffers_size 由于NGINX 使用/计算后者的默认值的方式。

无论哪种方式,都不要将这些缓冲区设置得太高并使用特定于您的应用程序的计算。任意高的值对您的 RAM 没有好处,因为每个连接都会使用这些缓冲区。

于 2019-08-18T21:30:53.020 回答
2

这个问题实际上可能与/var/lib/nginx/tmp目录中的容器权限有关(我们在 Alpine 上遇到过这种情况,但在其他发行版上也可能出现这种情况)。该目录归 nginx 用户所有,只能由 nginx 组写入。当请求缓冲区超过缓冲区大小时/var/lib/nginx/tmp,将用作临时写入位置,直到有足够的缓冲区释放以完成请求。写入tmp目录的请求是由www-user无权写入该位置的(同样在 Alpine Linux 中)发出的。

如果您在此处查看 Nginx的预安装脚本(同样适用于 Alpine Linux),您会发现该nginx组正在添加到该www-data组中。这是安装所必需的,因为 nginx 用户负责安装和引导 Nginx 实例。之后,所有 Nginx 职责都移交给www-data处理通过容器的 http 流量的用户。为了使www-data用户能够写入/var/lib/nginx/tmp目录,需要将目录的所有权更改为www-data用户或者www-data需要将用户添加到 nginx 组(这可能会带来安全问题)。

我在 Nginx 存储库上创建了一个问题,可以更好地解释这一点,并且如果您使用的是 Alpine Linux,还包含一个解决方法:https ://gitlab.alpinelinux.org/alpine/aports/-/issues/12669

虽然这是一个 Alpine Linux 问题,但我怀疑其他遇到此问题的人也遇到了类似的权限问题。可以在此处找到解释其工作原理的 Nginx 文档。

我知道这个问题很老了,但是我们最近遇到了这个问题并花了大约一周的时间来解决这个问题,因为简单地增加缓冲区大小对我们来说似乎不是一个可行的长期解决方案。希望这可以使其他人免于尝试遇到相同解决方案的一周头痛。

于 2021-05-13T20:44:46.937 回答