Dom*_*man 14 php fastcgi nginx
我正在设置LEMP堆栈以运行Drupal.我安装了Nginx和PHP-FastCGI.
Nginx工作正常,但任何运行PHP的尝试都给了我错误"502 Bad Gateway".
一个快速谷歌透露:nginx 502坏网关,并增加缓冲区大小解决了问题.
fastcgi_buffers 8 16k;
fastcgi_buffer_size 32k;
问题是为什么？
我的理解
从上一个链接看,似乎nginx正在向PHP-FastCGI发送请求而它没有响应.这些请求怎么样才能超时？
没有足够的时间来回应因为php很复杂(事实并非如此phpinfo();).现在我已经增加了缓冲区,我何时应该担心必须再次增加缓冲区？
ant*_*tov 11
如果您要检查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
这不是很好的解释,但它希望能帮助你更好地理解.
实际上，该问题仅与 直接相关fastcgi_buffer_size。这是一个非常特殊的缓冲区，它只保存响应中的 HTTP 标头。
如果您的应用程序发出大量Set-Cookie标头（或其他导致 HTTP 标头总大小的因素），则此处的默认缓冲区大小可能不够，您需要增加它。
要了解如何你需要增加它，你可以阅读我的超详细的书面记录在这里-这是关于proxy_buffer_size但fastcgi_缓冲区表现非常相似。引用基本命令：
curl -s -w \%{size_header} -o /dev/null https://example.com
-H如果需要，请确保针对正确的 URL 进行测试并通过 添加请求标头。
这将为您提供以字节为单位的标头大小。然后，您需要将结果值与 4k（内存页的典型大小）对齐。
所以如果你得到，例如 14342 字节，那么它需要设置：
fastcgi_buffer_size 16k;
棘手的部分不存在，而是事实上，当您增加此缓冲区大小时，由于 NGINX 使用/计算后者的默认值的方式，您需要增加fastcgi_buffer_size和/或fastcgi_busy_buffers_size 也增加。
无论哪种方式，都不要将这些缓冲区设置得太高，并使用特定于您的应用程序的计算。任意高的值对您的 RAM 没有好处，因为每个连接都会使用这些缓冲区。
小智 5
该问题实际上可能与容器中目录的权限有关（我们在 Alpine 上遇到过这种情况，但在其他发行版上也可能出现这种情况）/var/lib/nginx/tmp。该目录由 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 文档。
我知道这个问题很老了，但我们最近遇到了这个问题，并花了大约一周的时间来解决这个问题，因为简单地增加缓冲区大小对我们来说似乎不是一个可行的长期解决方案。希望这可以让其他人免于一周试图找到相同解决方案的头痛。