Centos + nginx + php-fpm + php include fastcgi_params php page can be accessed but the page is blank. fastcgi_params and fastcgi. conf are miserable, and centosng.pdf

Centos + nginx + php-fpm + php include fastcgi_params php page can be accessed but the page is blank. fastcgi_params and fastcgi. conf are miserable, and centosng.pdf

Today on centos, I found that the browser prompts 200 OK when accessing the page, and the html suffix is normal.

However, when accessing the php suffix, a blank page is returned, and no error information is found in all logs;

Then, in the nginx. conf server, write a sentence like return 405 if the path does not exist and debug it. It is found that my configuration can still reach that 405 normally.

NO content is returned ....

After searching for a few hours, my head was almost dizzy.

I still haven't figured out what's going on.

Finally, I thought about and compared fastcgi_params and fastcgi. conf. The head was dizzy. I did not see the difference after a few eyes.

I include the params file. If it is not the conf file, I am depressed. Why?

And then think about it. Are you sure you want to try conf?

A change. The page is refreshed and the content is displayed...

Looking back and looking at the two files, I still haven't found any difference... It's all dizzy.

Search for the two file names on the Internet and find out the differences between the two files;

There is also a history.

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

I understand the above statement as follows:

A long time ago, everyone included fastcgi_params and added a sentence

fastcgi_param SCRIPT_FILENAME /var/www/foo$fastcgi_script_name;

Because this command is in array format, it does not mean that the command with the same name will be replaced later.

Nginx developers gradually find that there is a problem with writing this root, or is it inconvenient?

So I gave a solution, or said that the variable cannot be written in the previous section? Is it hard-coded?

Later. however, it is estimated that many people are still using the old method. If you directly add this sentence to the front of the params file, it may be followed by nginx. conf appears at the same time, twice. this will lead to many inexplicable problems,

The path of the preceding command may be used in some places, while the path of the other place may use the following command.

Therefore, the author keeps params and adds a new file named fastcgi. conf.

But I just understood that these two files are the same... however, because this command is not provided, no files are sent to the php gate. so. blank content is returned ;;;;;;;

I am dizzy .... several hours ........ A piece of history ...... in fastcgi. add a few comments to the conf file to make it careless. I won't be so miserable without looking at it carefully ....