PHP-FPM + nginx 产生的权限被拒绝，但仅限于某些大页面

Question

我有一个 AWS Lightsail 实例（1GB RAM 实例）运行一个相对较新的网站（即几乎没有流量）。它正在运行 nginx 和 PHP-FPM 7.3（也尝试过 7.2）和 MariaDB。所有这些都在 CentOS 7 下。

在 AWS 免费套餐下一切正常。我运行了一个 T2.micro EC2 实例和一个 T2.micro RDS 实例。Lightsail 有点……更敏感。为了使 Lightsail 正常工作，我将 PHP-FPM 切换为ondemand

ondemand - 启动时不创建子项。当新请求连接时，子节点将被分叉。

我必须这样做，否则 MariaDB 会随机崩溃。这似乎不会影响下面的问题。

Wordpress 管理面板停止正常工作，每个人都说要CONCATENATE_SCRIPTS关闭。这有效......主要是。帖子和模板的编辑器出现故障。没有人能够给我一个线索为什么。环顾四周，我自己发现了一些东西。

不工作的页面没有完全加载。随着CONCATENATE_SCRIPTS上，CSS文件被加载在一个巨大的页面。因为这无法完全渲染，所以浏览器会忽略 CSS 和 JS 文件。CONCATENATE_SCRIPTS通过简单地将它们拆分为更小且易于加载的组件文件来解决这个问题。但是编辑页面无法拆分，调试底层问题一直让人抓狂。我收到 200 响应和一些数据

但是页面绘制不完整。我想说也许 80-90% 的 HTML 都在那里，但被切断了。在从这里开始的部分（JS 块）

wp.apiFetch.use( wp.apiFetch.createPreloadingMiddleware( {"\/":{"body":{"name":"S

它只是突然结束，而且每次都在同一点。就好像 PHP-FPM 或 nginx 刚刚停止，但没有任何错误日志（关于这种类型的设置的大多数其他问题都是针对根本没有绘制的页面）。更奇怪的是，它不是在较小的页面上这样做，而是在非常长的页面上这样做。没有偷窃时间，top并且实例似乎没有承受任何严重的负载，所以我不确定它为什么会这样做。我重新加载了所有文件，甚至建立了一个单独的 WP 站点来测试这个，他们都这样做了。

根据评论，我打开了 nginx 调试日志记录并发现

2019/08/07 02:33:08 [crit] 1461#0: *47 open() "/var/lib/nginx/tmp/fastcgi/3/00/0000000003" failed (13: Permission denied) while reading upstream, client: x.x.x.x, server: example.com, request: "GET /wp-admin/post-new.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000",

这没有任何意义，为什么它会在少数几个大文件上执行此操作。没有驱动器已满或接近它。我读过这个问题，但 nginx 和 PHP-FPM 都在apache. 删除 tmp 文件也没有修复它。目录归 拥有apache:root，但将它们更改为apache:apache无效。SELinux 似乎也不是罪魁祸首。我也没有使用proxy_cache.

Answer 1

首先，失败与FastCGI 缓冲有关，而不是与代理缓存有关。

这从/var/lib/nginx/tmp/fastcgi....

为什么你只在特别大的页面上遇到错误：如果你配置的 FastCGI 缓冲区不足以将来自 PHP-FPM 的整个响应放入内存中，并且这种情况在大响应中会更频繁地发生，NGINX 将尝试写入部分对临时文件的响应。

显然，保存 FastCGI 临时文件的目录的权限不允许 NGINX 将文件保存在那里，因此当响应“太大”时，它恰好在某个点失败。

该路径/var/lib/nginx/tmp/fastcgi还表明您没有使用官方的 NGINX 发行版，因为如果您使用了，那么您最终会/var/cache/nginx/fastcgi_temp拥有由nginx:root.

我建议使用股票，官方 NGINX 发行版。

但是 nginx 和 PHP-FPM 都在 apache 下运行

题外话，但是：无论如何，这是不正确的设置。正确的安装运行NGINX作为一个用户（可能是apache，nginx根据自己的，例如用户或其他任何东西），而应用程序的PHP-FPM池中运行foo。然后让您的nginx用户成为foo组成员。没有理由仅仅因为在给定服务器上只有一个应用程序就在单个用户下运行所有​​内容。

不管怎样，把它当作一个典型的chmod问题来对待：

• 检查用户 NGINX 工作进程与（user配置中的指令）一起运行
• 尝试使用该用户从上到下列出相关目录的文件，直到找到它停止工作的位置，然后递归修复权限。

例如，假设您的 NGINX 工作进程确实如您所说，由apache用户运行并且无法访问/var/lib/nginx/tmp/fastcgi：

sudo -u apache ls /var/ 

这行得通吗？权限没问题，可以通过NGINX工作进程的用户遍历到这个目录。重要的是要了解您需要能够遍历（如在rx权限中）所有上层目录，以便能够读取下层任何目录的内容。也就是说，我们的“最终目标”，这是/var/lib/nginx/tmp/fastcgi我们需要能够读取所有的/var，/var/lib等等。

如果阅读/var不起作用（尽管这表明某种损坏的系统），则需要让“其他人”阅读它，例如chmod o+rX /var

sudo -u apache ls /var/lib

这行得通吗？/var/lib 的权限很好。如果没有，您需要让其他人阅读它：chmod o+rX /var/lib

sudo -u apache ls /var/lib/nginx

这行得通吗？如果没有，请通过 来检查所有权和权限stat。然后确保 NGINX 用户是目录的所有者，/var/lib/nginx并且chmod（这次是“所有者”）允许它遍历目录：

chown apache:root /var/lib/nginx
chmod u+rX /var/lib/nginx

确保相同（由 NGINX 的用户拥有，可以被它读取（遍历）） /var/lib/nginx/tmp

最后，/var/lib/nginx/tmp/fastcgi您将需要 NGINX 用户能够执行所有读取、执行（遍历）和写入操作：

chown apache:root /var/lib/nginx/tmp/fastcgi 
chmod 0700 /var/lib/nginx/tmp/fastcgi

所以基本上它是一个冲洗，重复操作，同时遍历相关文件直到它工作。

通过尝试列出目录的内容并在其中创建文件来验证一切设置是否正确：

sudo -u apache ls /var/lib/nginx/tmp/fastcgi
sudo -u apache touch /var/lib/nginx/tmp/fastcgi/test.txt