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

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

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

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

就是没有内容返回....

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

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

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

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

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

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

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

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

而且还有一个历史.

FASTCGI_PARAMS VERSUS FASTCGI.CONF ? NGINX CONFIG HISTORYTweetThe 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 preferfastcgi_param SCRIPT_FILENAME $request_filename;as it takes the alias directive into account, fastcgi_new.conf anyone?Last updated:Sunday, July 7, 2013

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

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

fastcgi_param SCRIPT_FILENAME /var/www/foo$fastcgi_script_name;

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

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

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

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

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

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

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

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