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 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

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

很是久很是久曾经,你们都是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上加几下凝视说明,让粗心,没有细致看的我就不会这么慘了....