Question

我正在设置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();）。现在我增加了缓冲区，我何时应该担心必须再次增加缓冲区？

Answer 1

如果您要查看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

这不是很好的解释，但我希望能帮助你更好地理解。

Answer 2

实际上，问题仅与fastcgi_buffer_size直接相关。这是一个非常特殊的缓冲区，仅保留响应中的HTTP标头。

如果您的应用程序发出很多Set-Cookie标头（或其他导致HTTP标头总大小的信息），则此处的默认缓冲区大小可能不足，您需要增加它。

要了解如何，您需要增加它，您可以阅读我的超详细文章here-与proxy_buffer_size有关，但是fastcgi_缓冲区的行为非常相似。引用基本命令：

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

确保根据正确的URL进行测试，并在需要时通过-H添加请求标头。

这将为您提供标头大小（以字节为单位）。然后，您需要将结果值调整为4k（内存页的典型大小）。

例如，如果有的话14342字节，则需要设置：

fastcgi_buffer_size 16k;

棘手的部分并不存在，而是当您增加此缓冲区的大小时，还需要增加fastcgi_buffer_size和/或fastcgi_busy_buffers_size 由于NGINX使用/计算后者的默认值的方式。

无论哪种方式，都不要将这些缓冲区设置得太高，而要使用针对您应用的特定计算。任意高的值对您的RAM都不好，因为每个连接使用这些缓冲区。

Answer 3

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

如果您查看 Nginx（同样适用于 Alpine Linux）的预安装脚本 here，您会发现 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 问题，但我怀疑其他遇到此问题的人也遇到了类似的权限问题。可以在 here 中找到解释其工作原理的 Nginx 文档。

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

Nginx 502 Bad Gateway。通过增加缓冲区解决。为什么？

3 个答案: