我正在将 NGINX 设置为三个具有动态（PHP）和静态内容的小型 Web 应用程序的 SSL 反向代理。
在传递 PHP 请求时，从安全性和性能方面来看，什么被视为最佳实践？
是否应该将它们传递给请求的 Web 服务器（NGINX - 然后通过同一主机上的套接字或 TCP 将其传递给 PHP-FPM）还是应该将它们直接传递给 PHP-FPM 服务器？
我的所有 Web 应用和反向代理均位于 FreeBSD 上的单独 Jails 中。每个 Jail 都有自己的 NGINX Web 服务器和 PHP-FPM（或 uWSGI 和 Python）。
答案1
您的主 Nginx 应充当反向代理，并将 HTTP 请求转发到每个应用程序的相应 Web 服务器。如果主反向代理具有对应用程序 jail 的文件级访问权限，则最好使用 UNIX 套接字与其 Web 服务器通信，但就您而言，您别无选择，只能使用 TCP。
使用 TCP 时，请确保设置keepalive参数以始终保持一定数量的打开连接，这样您就不必在每个请求上打开和关闭连接以获得更好的性能。该参数的参数是要保持打开的连接数，例如 10 个就足够了。
在您的监狱中，其中的 Web 服务器应该使用 UNIX 套接字与其 PHP-FPM 进行通信以获得更好的性能（TCP 比 UNIX 套接字具有更多的开销，因此尽可能使用后者）。
最后，我认为让主反向代理直接与监狱内的 PHP-FPM 通信不会带来重大安全问题，但这意味着您还应该根据监狱内的 PHP-FPM 配置主反向代理。我宁愿避免这种情况，我更希望监狱是独立的，并在默认端口上公开单个 HTTP 端点，并让监狱内的 Nginx 处理所有 PHP-FPM 内容。如果您需要更改 PHP-FPM 方面的某些内容，只需在监狱中进行更改，而无需触及主 Nginx 反向代理。
另外我建议你尝试一个更轻量的监狱网络服务器，比如 Lighttpd，因为你真的不需要里面有太多的功能，尽管 Lighty 的配置语法非常糟糕这应该不是什么问题。
关于你最后一条评论
现在我只需要找出在后端设置哪些设置以及在代理中设置哪些设置（cache-control、keepalive、error_page 等...）
我提到的 keep-alive 参数应该在主 Nginx 反向代理的块中设置upstream，并且只影响反向代理 <-> jail 服务器通信，与客户端和服务器之间的 HTTP keep-alive 无关。对于浏览器和服务器之间的 keepalive，应该在您这边的最后一个端点上完成，即反向代理。另一方面，缓存控制标头依赖于应用程序（因为不同的应用程序可能需要不同的设置），应该在应用程序的 jail 中单独设置。尝试在每个应用程序的 jail 中放置尽可能多的设置，并且只在极端情况下修改反向代理的配置，例如连接级别设置（HTTP keepalive、TLS 等）。