我有一个自定义安装nginx和PHP -FMEM拱桥Linux。 我会在下面发布我的configuration。 我认为我现在已经阅读了大约6次这两个程序的文档，但是我已经达到了一个我不能从系统中挤出更多的信息，因此没有任何东西留给谷歌的地步。 这是瘦的：
我从头编译了nginx和php（我对此非常熟悉，所以大概没有问题）。 我有nginx设置正确的服务，它始终如一：php文件通过unix套接字（这是既存在和读取/写入访问的http用户，这是用户既nginx和php-fpm运行），而现有的常规文件得到服务。 调用文件夹和调用不存在的文件都将被发送到/index.php文件。 所有权限都是按顺序的。
我的网页得到服务，直到有一个PHP错误。 该错误被转储到nginx的错误日志中，并且来自该特定subprocessphp-fpm的页面的所有进一步请求都返回空白。 他们确实似乎被处理，事实certificate，随后调用错误的文件继续将错误消息转储到日志文件，但有缺陷和干净的文件都返回完全空白与200状态代码。
最让我惊讶的是，我发现如果我坐在上面几分钟，违规的php-fpmsubprocess不会死，但是下一个请求会产生一个新进程，新的进程会正确地提供页面。 从那以后，每一个请求都是空的，而另一个请求则恢复正常，大概是因为subprocess轮stream服务请求。
我的testing如下：
// web directory listing: mysite/ --index.php --bad_file.php --imgs/ ----test.png ----test2.png
index.php文件：
<?php die('all cool'); ?>
bad_file.php *：
<?php non_existent_function($called); ?>
* 注意：我以前发布bad_file.php来包含行$forgetting_the_semicolon = true bad_file.php $forgetting_the_semicolon = true ，但发现这实际上并没有产生我正在谈论的错误（这是一个简单的例子，我现在已经自己实现了系统）。 但是，上面的代码会重现错误，因为它会产生致命错误而不是parsing错误。
从terminaltesting呼叫：
curl -i dev.mysite.com/ # "all cool" curl -i dev.mysite.com/index.php # Redirected to / by nginx curl -i dev.mysite.com/imgs # "all cool" curl -i dev.mysite.com/imgs/test.png # returns test.png, printing gibberish curl -i dev.mysite.com/nofile.php # "all cool" curl -i dev.mysite.com/bad_file.php # blank, but error messages added to log curl -i dev.mysite.com/ # blank! noooooooo!! curl -i dev.mysite.com/ # still blank! noooooooo!! #wait 5 or 6 minutes (not sure how many - probably corresponds to my php-fpm config) curl -i dev.mysite.com/ # "all cool" curl -i dev.mysite.com/ # blank! curl -i dev.mysite.com/ # "all cool" curl -i dev.mysite.com/ # blank! #etc....
nginx.conf：
user http; worker_processes 1; events { worker_connections 1024; } http { include mime.types; default_type text/plain; sendfile on; keepalive_timeout 65; index /index.php; server { listen 127.0.0.1:80; server_name dev.mysite.net; root /path/to/web/root; try_files /maintenance.html $uri @php; location = /index.php { return 301 /; } location ~ .php$ { include fastcgi_params; fastcgi_pass unix:/usr/local/php/var/run/php-fpm.sock; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } location @php { include fastcgi_params; fastcgi_pass unix:/usr/local/php/var/run/php-fpm.sock; fastcgi_param SCRIPT_FILENAME $document_root/index.php; } } }
PHP-fpm.conf：
[global] pid = run/php-fpm.pid error_log = log/php-fpm.log log_level = warning [www] user = http group = http listen = var/run/php-fpm.sock listen.owner = http listen.group = http listen.mode = 0660 pm = dynamic pm.max_children = 5 pm.start_servers = 1 pm.min_spare_servers = 1 pm.max_spare_servers = 3
根据请求php.ini
所有页面都按预期的方式提供， 直到出现一个php错误 ，此时所有对该特定php-fpmsubprocess的后续请求都会被处理，但是会以完全空白的页面的forms返回。 发生的错误会报告并继续在nginx错误日志文件中报告。
如果有人有任何想法，把它们扔给我。 我死在水里直到我知道了。 顺便说一句，如果有人知道php-fpm的合法文档来源，那也是有帮助的。 php-fpm.org似乎几乎是无用的，php.net的fpm文档也是如此。
谢谢！
从昨天起我一直在搞这个，看起来实际上是一个输出缓冲的bug。 在尝试了所有的东西之后，阅读所有的东西，发疯，我终于关闭了输出缓冲，并且工作正常。 我在这里提交了一个错误报告。
对于那些不知道的人来说，输出缓冲是php.ini中的一个设置，它可以防止php一收到输出就越发送输出。 不是完全关键的功能。 我把它从4096切换到关闭：
;php.ini: ... ;output_buffering = 4096 output_buffering = Off ...
希望这可以帮助别人！