ERR_CONNECTION_REFUSED nginx PHP new droplet

@broodforge

There’s a few things we can check, though first I’d simplify your server block to avoid any potential issues. Stripping out the comments and configuration that isn’t helping would look like this the below.

I’ll use this to build on, so make sure you check the bottom of the post for the actual configuration.

server {
    listen 80;
    listen [::]:80;

    root /var/www/mysite.com/html;

    index index.php index.html index.htm index.nginx-debian.html;

    server_name mysite.com www.mysite.com;

    location / {
        try_files $uri $uri/ =404;
    }
                                                        
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php7.0-fpm.sock;
    }

    location ~ /\.ht {
        deny all;
    }
}

When it comes to configuration, if you don’t need it, don’t include it – just to keep things clean.

Now, when it comes to PHP-FPM, ideally, I’d change this block:

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php7.0-fpm.sock;
    }

to this:

location ~ [^/]\.php(/|$) {
    fastcgi_split_path_info ^(.+?\.php)(/.*)$;
    fastcgi_pass unix:/run/php/php7.0-fpm.sock;
    fastcgi_index index.php;

    include snippets/fastcgi-php.conf;
}

I would then backup snippets/fastcgi-php.conf and replace everything in it with:

fastcgi_connect_timeout 60;
fastcgi_send_timeout 180;
fastcgi_read_timeout 180;
fastcgi_buffer_size 512k;
fastcgi_buffers 512 16k;
fastcgi_busy_buffers_size 1m;
fastcgi_temp_file_write_size 4m;
fastcgi_max_temp_file_size 4m;
fastcgi_intercept_errors off;

fastcgi_param SCRIPT_FILENAME   $request_filename;
fastcgi_param PATH_INFO         $fastcgi_path_info;
fastcgi_param PATH_TRANSLATED   $document_root$fastcgi_path_info;
fastcgi_param QUERY_STRING      $query_string;
fastcgi_param REQUEST_METHOD    $request_method;
fastcgi_param CONTENT_TYPE      $content_type;
fastcgi_param CONTENT_LENGTH    $content_length;
fastcgi_param SCRIPT_NAME       $fastcgi_script_name;
fastcgi_param REQUEST_URI       $request_uri;
fastcgi_param DOCUMENT_URI      $document_uri;
fastcgi_param DOCUMENT_ROOT     $document_root;
fastcgi_param SERVER_PROTOCOL   $server_protocol;
fastcgi_param REQUEST_SCHEME    $scheme;
fastcgi_param HTTPS             $https if_not_empty;
fastcgi_param HTTP_PROXY        "";
fastcgi_param GATEWAY_INTERFACE CGI/1.1;
fastcgi_param SERVER_SOFTWARE   nginx/$nginx_version;
fastcgi_param REMOTE_ADDR       $remote_addr;
fastcgi_param REMOTE_PORT       $remote_port;
fastcgi_param SERVER_ADDR       $server_addr;
fastcgi_param SERVER_PORT       $server_port;
fastcgi_param SERVER_NAME       $server_name;
fastcgi_param REDIRECT_STATUS   200;

So what we end up with us a server block that looks like:

server {
    listen 80;
    listen [::]:80;

    root /var/www/mysite.com/html;

    index index.php index.html index.htm index.nginx-debian.html;

    server_name mysite.com www.mysite.com;

    location / {
        try_files $uri $uri/ =404;
    }
                                                        
    location ~ [^/]\.php(/|$) {
        fastcgi_split_path_info ^(.+?\.php)(/.*)$;
        fastcgi_pass unix:/run/php/php7.0-fpm.sock;
        fastcgi_index index.php;

        include snippets/fastcgi-php.conf;
    }

    location ~ /\.ht {
        deny all;
    }
}

Beyond the changes to how PHP is handled, everything else looks good unless you’re using WordPress, in which case I’d change one more line:

try_files $uri $uri/ =404; => try_files $uri $uri/ /index.php?$args;

…

Once the changes have been made, run service nginx restart and then check to see if NGINX is running as expected.

…

That being said, also on the PHP-FPM side, you need to make sure that your files and directories are owned by the same user that PHP-FPM is running as. In most cases, on an un-modified version (i.e. you’ve not created additional pool files), that’ll be www-data, so I’d run:

chown -R www-data:www-data /var/www/mysite.com/html

and make sure PHP-FPM is indeed running as well.

Hmmmm…it could be a php issue… Darn…how to check if PHP is running?

@broodforge

Please post your server block configuration – starting with server { and ending with }.

If NGINX isn’t running, nothing will be logged to NGINX’s error or access logs, so we need to check the server block(s) and then make sure NGINX is actually running as expected.

Hi @broodforge

Did you change the parameter error_log in your Nginx configuration? By default you should have a file /var/log/nginx/error.log which is created and contains information (no matter if there is errors or not, since it will log every time you restart Nginx).

Is Nginx even running? service nginx status