Record the low energy operation of debugging nginx Vhost once

Time:2020-3-5

Recently, I am learning the specific content of fast CGI protocol. I use tcpdump to grasp the TCP packets sent by nginx to PHP FPM. So I have to build a simple environment on MAC and run a small demo. We have both nginx and PHP. When we come back to match a Vhost of nginx, it becomes. Who knows that we spent half a day on Vhost. Hard top.

Because the previous nginx configuration is operated on the virtual machine provided by the company, it is just to test the conf file of the previous project, change the root path, server_name, and finally reload it. But the fluid from my cardiovascular system suddenly rushed to my head, and I decided to write one myself.

In fact, I’ve read nginx’s manual before. I understand the functions and configurations of HTTP, server and location modules, so I started to write. First of all, I now write a test.php file in / users / zonay / www /. Then I configure Vhost to see the effect first.

The first server I wrote is as follows:

server {
        listen       8848;
        server_name  localhost;
       
        location / {
            root  /Users/zonghay/www/;
            index  index.html index.htm;
        }
}

The browser accesses http: / / localhost: 8848 and finds an error of 404.
404 well, I’m sure I can’t find it. What can’t I find? Think about it for a while. I wrote the test.php file myself, but the nginx configuration went to index.html and index.htm. Let’s change the file name of PHP and the configuration file of nginx to the following

server {
        listen       8848;
        server_name  localhost;

        location / {
            root  /Users/zonghay/www/;
            index  index.html index.htm index.php;
        }
}

Restart nginx and send the request
This time it’s not 404. This time it’s whiteboard. Instead of outputting anything, it’s downloading the file index.php. Alas, why?
After the nginx is matched to the index.php file, it is found that it is not an HTML resource, so nginx will return as the content type of application / octet stream. Let’s take a look at the response of HTTP in F12.

HTTP/1.1 200 OK
Server: nginx/1.17.3
Date: Wed, 13 Nov 2019 13:25:25 GMT
Last-Modified: Wed, 13 Nov 2019 13:23:34 GMT
Content-Type: application/octet-stream
Content-Length: 18
ETag: “5dcc03d6-12”
Accept-Ranges: bytes

But how to solve it, of course, is to tell nginx who is going to handle this file. Well, let’s continue to mend the wall, add the location block that matches the PHP file, and tell nginx to leave the file to the PHP FPM listening to the 9000 port of the machine.

server {
        listen       8848;
        server_name  localhost;

        location / {
            root  /Users/zonghay/www/;
            index  index.html index.htm index.php;
        }
       
        location ~ .*\.php$ {
            fastcgi_pass 127.0.0.1:9000;
        }
}

Continue to restart and refresh

I’m looking forward to finding out that this time it’s neither 404 nor download. It’s a whiteboard. I’m broken. But calm down and analyze. Why didn’t you come back? It is possible that PHP FPM did not process this file or did not process it correctly and returned null. After careful comparison of my virtual machine Vhost configuration and this season’s configuration, I found that I may have made a low-level mistake. As we all know, what is the full name of PHP FPM? It’s called PHP fast CGI manager. It’s an application that implements the fast CGI protocol. You nginx told people to deal with this file, but didn’t tell them what protocol to deal with it. It’s like when you arrive at a restaurant and ask someone to fry you with meat, but you don’t know what to fry. They will certainly ignore you. So I wrote a final version by comparing the differences between the two configuration files while I was Bing

server {
        listen       8848;
        server_name  localhost;
        root  /Users/zonghay/www/;
        index  index.html index.htm index.php;

        location ~ .*\.php$ {
            include fastcgi_params;
            fastcgi_pass 127.0.0.1:9000;
            fastcgi_index index.php;
        }
}

The included fast CGI ﹣ params file contains the K-V key value pairs necessary for the fast CGI protocol. As for the effect of these key value pairs, I’ll write another one after I finish the follow-up research on the fast CGI protocol. In the end, my little demo ran through without any danger. Looking at the words “Hello world” on the screen, I feel very ashamed. I’ve been working for a year, and I’m convinced that I can make such a low-level mistake in nginx configuration.