Score:0

nginx empty response after reboot

in flag
Sam

I bought a new VPS, installed Ubuntu server 20.04, nginx,php7.4-fpm,MariaDB via apt.
I scp uploaded my (working on my Ubuntu 20.04 laptop) PHP project. I could see the 'thank you for using nginx' page,both via ssh curl and through browser from my laptop, but when I tried to use dm.mydomain.tld, both returned noting. The request was logged in access.log
The ownership of /var/www/dm is root, same as /var/www/html. UFW disabled, no SELINUX.
The dm.conf is as follows:


server {
    listen 443 ssl; #http2 ;
    listen [::]:443 ssl; #http2;

    root /var/www/dm;
        ssl_certificate /etc/ssl/certs/cloudflaresource.pem;
        ssl_certificate_key /etc/ssl/private/cloudflaresource.key;

    # Add index.php to the list if you are using PHP
    index index.php; # index.html index.htm index.nginx-debian.html;

    server_name dm.mydomain.tld;
        autoindex on;
    location / {
        # First attempt to serve request as file, then
        # as directory, then fall back to displaying a 404.
        try_files $uri $uri/ =404;
    }
    location ~ \.php$ {
        fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
    }
}

curl output from ssh console:

root@VPS:~# curl -vk https://dm.mydomain.tld
*   Trying 127.0.0.1:443...
* TCP_NODELAY set
* Connected to dm.mydomain.tld (127.0.0.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: O=CloudFlare, Inc.; OU=CloudFlare Origin CA; CN=CloudFlare Origin Certificate
*  start date: Mar  5 07:31:00 2022 GMT
*  expire date: Mar  1 07:31:00 2037 GMT
*  issuer: C=US; O=CloudFlare, Inc.; OU=CloudFlare Origin SSL Certificate Authority; L=San Francisco; ST=California
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x561a6f79e880)
> GET / HTTP/2
> Host: dm.mydomain.tld
> user-agent: curl/7.68.0
> accept: */*
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 200 
< server: nginx/1.18.0 (Ubuntu)
< date: Sat, 05 Mar 2022 13:58:11 GMT
< content-type: text/html; charset=UTF-8
< 
* Connection #0 to host dm.mydomain.tld left intact

you can see that the response is empty.

Additionally, this is the access.log entry.

127.0.0.1 - - [05/Mar/2022:15:44:13 +0100] "GET / HTTP/2.0" 200 0 "-" "curl/7.68.0"

UPDATE: I created an html file and curl it, it worked fine. But for a simple php helloworkd, it doesn't work.

Sam avatar
in flag
Sam
PHP-fpm is up and running. I can tell by systemctl.
Score:0
in flag
Sam

Since the problem aroused after reboot, so I checked the unix domain socket. The ownership of /var/run/php/php7.4-fpm.sock (run ll in /var/run/php/) was www-data, which shouldn't be as I didn't change that.
So I guessed that it was created by nginx, as there's none. By simply change the entry in dm.conf, everything worked:

/var/run/php/php-fpm.sock

Also, remember to uncomment this line:

include snippets/fastcgi-php.conf;

What bothered me was that there's no error reported.

Sam avatar
in flag
Sam
I also tried to uninstall and reinstall php, which of course did not work.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.