图片 1

centos+nginx+php-fpm+php include fastcgi_params php页面能访问但空白,被fastcgi_params与fastcgi.conf害惨了

今天在centos上折腾这块是发现老是访问页面时,浏览器中提示是200
ok.且访问html后缀却是正常出现内容.

当你将默认的访问路径改后(nginx.conf中的root
之后的路径),同时应该将/home/wwwroot/default/.user.ini 中的路径也改了!

但是访问php后缀却返回空白页面,同时查看所有的log没有发现任何出错信息;

.user.ini 是隐藏文件,需要 ls -a 查看;

再在nginx.conf中的server中写如果 路径不存在就return
405这样的断句来调试,发现我的配置还是正常能走到那个405.

第一步:你先确定你的pathinfo路由开启了,配置如下:

就是没有内容返回….

图片 1

找了几个小时.头都快晕了.

lnmp
v1.1上,修改对应虚拟主机的配置文件(/usr/local/nginx/conf/vhost/域名.conf)

还是没有搞明白怎么回事.

去掉#include pathinfo.conf前面的#,把try_files $uri =404; 前面加上#
注释掉。

最后想想和比较了下fastcgi_params与fastcgi.conf,头已经晕了,看了几眼,没看出差别来了.

1.2,1.3上,修改对应虚拟主机的配置文件(/usr/local/nginx/conf/nginx.conf)
将include enable-php.conf;替换为include enable-php-pathinfo.conf;

我包含的是params这个文件,不是conf这个.我就郁闷死了…怎么回事?

修改pathinfo需要重启nginx生效。

然后想想.是不是试试饮食一下conf这个试试看?

第二步:路由重写设置成功

一改变.刷新页面,竟然出来内容了…

 1 server { 2     listen   80; 3     server_name www.aaa.com; 4     root "你的项目路径"; 5     include enable-php-pathinfo.conf;//开启pathinfo 6    location /nginx_status 7     { 8       stub_status on; 9       access_log off;10     }11     location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$12     {13       expires   30d;14     }15    location ~ .*\.?$16     {17       expires   12h;18     }19     location ~ /.well-known {20       allow all;21     }22     location ~ /\.23     {24       deny all;25     }26     location ~ /index.php {27       fastcgi_pass 127.0.0.1:9000;28       fastcgi_index index.php;29       fastcgi_param SCRIPT_FILENAME $document_root/index.php;30       include    fastcgi_params;31       fastcgi_param APPLICATION_ENV dev;32     }33     location / {34      index index.html index.htm index.php l.php;35      autoindex on;36      if (!-e $request_filename){37        rewrite ^/ /index.php last;38      }39     }40     error_page 500 502 503 504 /50x.html;41     location = /50x.html {42       root html;43     }44     location ~ \.php(.*)$ {45       fastcgi_pass 127.0.0.1:9000;46       fastcgi_index index.php;47       fastcgi_split_path_info ^.+\.php)(/?.+)$;48       fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;49       fastcgi_param PATH_INFO $fastcgi_path_info;50       fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info;51       include    fastcgi_params;52     }53   }

再回头仔细看眼二个文件.竟然还是没发现有什么区别….已经全部晕了.

第三步:再次访问,如果是500/空白页面

使用二个文件名在网上查找一下,才发现,这二个文件真有区别;

在你框架index.php开头,打开报错,如下:

而且还有一个历史.

error_reporting;

FASTCGI_PARAMS VERSUS FASTCGI.CONF – NGINX CONFIG HISTORY Tweet The nginx source install (and by extension package managers) includes two FastCGI configuration files, fastcgi_params and fastcgi.conf that differ only a tiny bit. To this day they still cause confusion amongst new users due to package managers.  The difference between the two files in the source install is the simple line of:  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; The difference between the two files in most distributions package repositories is nothing, they essentially modified fastcgi_params to match fastcgi.conf.  What this line does is tell PHP which file it should execute, without this nginx and PHP cannot work together. This sounds like a good line to include in the shipped FastCGI configuration file and indeed Igor Sysoev thought so as well. However, due to the configurations of the time this wasn’t as easy as simply adding it in.  Back in the days of 0.6.x when I started using nginx and a few years before this change happened a typical configuration example would look like this.  location ~ \.php$ {     include fastcgi_params;     fastcgi_param SCRIPT_FILENAME /var/www/foo$fastcgi_script_name;     fastcgi_pass backend; } Due to community documentation efforts on the wiki people slowly started using the $document_root variable instead of hard coding the root path, however, many people were still using the above configuration many years later.  Because of how array directives inherit and interact the people using the old configuration style made it impossible to include the line in fastcgi_params. Doing this would have meant that SCRIPT_FILENAME would be defined twice and both would be sent to the backend, potentially causing confusing behaviour.  In 0.8.30 (released: 15th of December 2009) Igor then included fastcgi.conf which was the same as fastcgi_params except including the improved SCRIPT_FILENAME fastcgi_param. This meant that the community could now start recommending people include fastcgi.conf instead of recommending moving SCRIPT_FILENAME into fastcgi_params. New articles on the wiki mostly used this, the popular articles were slowly changed to use it and we were promoting it in the IRC support channel.  Of course, an issue back then was that package managers gave nginx very little love and were many versions behind, usually something like 0.6.x versus 0.8.x. The fastcgi.conf file was not included for these people. When they eventually did update they shipped with a fastcgi.conf and a modified fastcgi_params leaving us with a situation where the source install actually differed from the repository install in a non-significant way. While not often, this does still cause the occasional confusing in the IRC channel.  As an aside, I actually prefer  fastcgi_param SCRIPT_FILENAME $request_filename; as it takes the alias directive into account, fastcgi_new.conf anyone?  Last updated:Sunday, July 7, 2013

ini_set(‘display_errors’, ‘1’);
默认是没有开启报错的,设置如下:

关于上面的说法我理解是:

1、先打开php的错误提示

很久很久以前,大家都是include fastcgi_params,而且在后面加上一句

将 php.ini中的 display_errors = Off 修改为 On;

fastcgi_param SCRIPT_FILENAME /var/www/foo$fastcgi_script_name;

2、开启nginx的报错

因为这个指令它是数组形态的,并不会说,同名的指令,后面会替换掉前面的.

在 /usr/local/php/etc/php-fpm.conf 加上

而nginx的开发者慢慢发现大家写死这个root有问题.或是不方便?

php_admin_value[error_log] =
/usr/local/php/var/log/php_errors.log
php_admin_flag[log_errors] = on

于是给了一个方案,或是说,前面的时候,那块还不能写变量?里面是硬编码写死的?

有时可能错误日志文件不自动创建,可以执行:touch
/usr/local/php/var/log/php_errors.log && chown www:www
/usr/local/php/var/log/php_errors.log

后面可以了.但是估计很多人还是旧写法,如果直接把这句加入params这个文件的前面话,就会可能跟nginx.conf中同时出现,了二次.就会导致很多莫名的问题,

然后你访问,会得到以下的报错:

有可能某些地方会用前面一个指令的路径,而另一个地方会可能用到后面一个指令.

1 PHPWarning:require():open_basedirrestrictionineffect.File(/home/wwwroot/default/laravel/bootstrap/autoload.php)isnotwithintheallowedpath:(/home/wwwroot/default/laravel/public:/tmp/:/var/tmp/:/proc/)in/home/wwwroot/default/laravel/public/index.phponline222 3 PHPWarning:require(/home/wwwroot/default/laravel/bootstrap/autoload.php):failedtoopenstream:Operationnotpermittedin/home/wwwroot/default/laravel/public/index.phponline224 5 PHPFatalerror:require():Failedopeningrequired‘/home/wwwroot/default/laravel/public/../bootstrap/autoload.php‘(include_path=‘.:/usr/local/php/lib/php‘)in/home/wwwroot/default/laravel/public/index.phponline22

所以,作者保留params,新加一个文件叫fastcgi.conf.

解决
检查php.ini的 open_basedir的参数 将其开启,写为自己的项目路径
如果是lnmp,检查 path/nginx/conf/fastcgi.conf里的 $document_root参数
fastcgi_param PHP_ADMIN_VALUE
“open_basedir=$document_root/:/tmp/:/proc/:/home/stone/dsales/”;
(/home/stone/dsales/为项目路径)
注意:如果在fastcgi.conf里没有 fastcgi_param
PHP_ADMIN_VALUE……自行添加
如果这样还是报错的话,那就改为fastcgi_param PHP_ADMIN_VALUE
“open_basedir=NULL”;

而我却刚好理解成这二个文件是相同的…但是因为没有提供这个指令,所以,导致没有文件发送到php
gate中.那么.就返回了空白内容;;;;;;;

  这样的话你就应该可以访问到项目了。。。

我晕死了….几个小时……..一段历史……如果在fastcgi.conf上加几下注释说明,让粗心,没有仔细看的我就不会这么惨了….

版权声明:本文为博主原创文章,未经博主允许不得转载。