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上加幾下凝視說明,讓粗心,沒有細緻看的我就不會這麼慘了....