Nginx is a very popular web server these days. This article will show you some common errors when running an Nginx web server and possible solutions. This is not a complete list. If you still can’t fix the error after trying the advised solutions, please check your Nginx server logs under /var/log/nginx/ directory and search on Google to debug the problem.

Unable to connect/Refused to Connect#

If you see the following error when trying to access your website:

Firefox can’t establish a connection to the server at www.example.com

or

www.example.com refused to connect

It could be that

1. Nginx isn’t running. You can check Nginx status with sudo systemctl status nginx. Start Nginx with sudo systemctl start nginx. If Nginx fails to start, run sudo nginx -t to find if there is anything wrong with your configuration file. And check the journal (sudo jounalctl -eu nginx) to find out why it fails to start.
2. Firewall blocking ports 80 and 443. If you use the UFW firewall on Debian/Ubuntu, run sudo ufw allow 80,443/tcp to open TCP ports 80 and 443. If you use Firewalld on RHEL/CentOS/Rocky Linux/AlmaLinux, run sudo firewall-cmd --permanent --add-service={http,https}, then sudo systemctl reload firewalld to open TCP ports 80 and 443.
3. Nginx isn’t listening on the right network interface. For example, Nginx isn’t listening on the server’s public IP address.

404 Not Found#

404 not found means Nginx can’t find the resources your web browser asks for. The reason could be:

1. The web root directory doesn’t exist on your server. In Nginx, the web roor directory is configured using the root directive, like this: root /usr/share/nginx/linuxbabe.com/;.  Make sure your website files (HTML, CSS, JavaScript, PHP) are stored in the correct directory.
2. PHP-FPM isn’t running. You can check PHP-FPM status with sudo systemctl status php7.4-fpm (Debian/Ubuntu) or sudo systemctl status php-fpm.
3. You forgot to include the try_files $uri /index.php$is_args$args; directive in your Nginx server config file. This directive is needed to process PHP code.
4. Your server has no free disk space. Try to free up some disk space. You can use the ncdu utility (sudo apt install ncdu or sudo dnf install ncdu) to find out which directories are taking up huge amount of disk space.

403 Forbidden#

This error means that you are not allowed to access the request resources. Possible scenario includes:

• The website administrator blocks public access to the requested resources with an IP whitelist or other methods.
• The website could be using a web application firewall like ModSecurity, which detected an intrusion attack, so it blocked the request.

Some web applications may show a different error message when 403 forbidden happens. It might tell you that “secure connection failed”, while the cause is the same.

500 Internal Server Error#

This means there is some error in the web application. It could be that

1. The database server is down. Check MySQL/MariaDB status with sudo systemctl status mysql. Start it with sudo systemctl start mysql. Run sudo journalctl -eu mysql to find out why it fails to start. MySQL/MariaDB process could be killed due to out-of-memory issue.
2. You didn’t configure Nginx to use PHP-FPM, so Nginx doesn’t know how to execute PHP code.
3. If your web application has a built-in cache, you can try flushing the app cache to fix this error.
4. Your web application may produce its own error log. Check this log file to debug this error.
5. Your web application may have a debugging mode. Turn it on and you will see more detailed error messages on the web page. For example, you can turn on debugging mode in the Modoboa mail server hosting platform by setting DEBUG = True in the /srv/modoboa/instance/instance/settings.py file.

Nginx Shows the default page#

If you try to set up an Nginx virtual host and when you type the domain name in your web browser, the default Nginx page shows up, it might be

• You didn’t use a real domain name for the server_name directive in your Nginx virtual host.
• You forgot to reload Nginx.

The page isn’t redirecting properly#

Firefox displays this error as The page isn’t redirecting properly. Google Chrome shows this error as www.example.com redirected you too many times.

This means you have configured Nginx redirection too many times. For example, you may have added an unnecessary return 301 directive in the https server block to redirect HTTP to HTTPS connection.

If you have set up a page cache such as Nginx FastCGI cache, you need to clear your server page cache.

504 Gateway time-out#

This means the upstream like PHP-FPM/MySQL/MariaDB isn’t able to process the request fast enough. You can try restarting PHP-FPM to fix the error temporarily, but it’s better to start tuning PHP-FPM/MySQL/MariaDB for faster performance.

Memory Size Exhausted#

If you see the following line in your Nginx error log, it means PHP reached the 128MB memory limit.

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 57134520 bytes)

You can edit the php.ini file (/etc/php/7.4/fpm/php.ini) and increase the PHP memory limit.

memory_limit = 512M

Then restart PHP7.4-FPM.

sudo systemctl restart php7.4-fpm

If the error still exists, it’s likely there’s bad PHP code in your web application that eats lots of RAM.

PR_END_OF_FILE_ERROR#

1. You configured Nginx to rediect HTTP request to HTTPS, but there’s no server block in Nginx serving HTTPS request.
2. Maybe Nginx isn’t running?
3. Sometimes, the main Nginx binary is running, but a worker process can fail and exit due to various reasons. Check the Nginx error log (/var/log/nginx/error.log) to debug.

PHP-FPM Upstream Time Out#

Some folks can find the following error in Nginx error log file ( under /var/log/nginx/).

[error] 7553#7553: *2234677 upstream timed out (110: Connection timed out) while reading response header from upstream

Possible solutions:

1. Restart PHP-FPM.
2. Upgrade RAM.

Resource temporarily unavailable#

Some folks can find the following error in Nginx error log file ( under /var/log/nginx/).

connect() to unix:/run/php/php7.4-fpm.sock failed (11: Resource temporarily unavailable)

This usually means your website has lots of visitors and PHP-FPM is unable to process the huge amounts of requests. You can adjust the number of PHP-FPM child process, so it can process more requests.

Edit your PHP-FPM www.conf file. (The file path varies depending on your Linux distribution.)

sudo /etc/php/7.4/fpm/pool.d/www.conf

The default child process config is as follows:

pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

The above configuration means

• PHP-FPM dynamically create child processes. No fixed number of child processes.
• It creates at most 5 child processes.
• Start 2 child processes when PHP-FPM starts.
• There’s at least 1 idle process.
• There’s at most 3 idle process.

The defaults are based on a server without much resources, like a server with only 1GB RAM. If you have a high traffic website, you probabaly want to increase the number of child proceses, so it can serve more requests.

pm = dynamic
pm.max_children = 20
pm.start_servers = 8
pm.min_spare_servers = 4
pm.max_spare_servers = 12

Make sure you have enough RAM to run more child processes. Save and close the file. Then restart PHP-FPM. (You might need to change the version number.)

sudo systemctl restart php7.4-fpm

To monitor the health of PHP-FPM, you can enable the status page. Find the following line in the PHP-FPM www.conf file. Note that the following

;pm.status_path = /status

Remove the semicolon to enable PHP-FPM status page. Then restart PHP-FPM.

sudo systemctl restart php7.4-fpm

Then edit your Nginx virtual host file. Add the following lines.  The allow and deny directives are used to restrict access. Only the whitelisted IP addresses can access the status page.

location ~ ^/(status|ping)$ {
        allow 127.0.0.1;
        allow your_other_IP_Address;
        deny all;

        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_index index.php;
        include fastcgi_params;
        #fastcgi_pass 127.0.0.1:9000;
        fastcgi_pass   unix:/run/php/php7.4-fpm.sock;
}

Save and close the file. Then test Nginx configurations.

sudo nginx -t

If the test is successful, reload Nginx for the changes to take effect.

sudo systemctl reload nginx

Sample PHP-FPM status page.

The PHP-FPM www.conf file give you good explanation about what each parameter means.

If PHP-FPM is very busy and unable to serve a request immediately, it will queue this request. By default, there can be at most 511 pending requests, determinted by the listen.backlog parameter.

listen.backlog = 511

If you see the following value on the PHP-FPM status page, it means there has never been a request put in the queue, i.e. your PHP-FPM can process requests quickly.

listen queue:         0
max listen queue:     0

If there are 511 pending requests in the queue, it means your PHP-FPM is very busy, so you should increase the number of child processes.

You may also need to change the Linux kernel net.core.somaxconn setting, which defines max number of connections allowed to a socket file on Linux, such as the PHP-FPM Unix socket file. By default, its value is 128 before kernel 5.4 and 4096 starting with kernel 5.4.

linuxbabe@ubuntu:~$ sysctl net.core.somaxconn
net.core.somaxconn = 128

If you run a high traffic website, you can use a big value. Edit /etc/sysctl.conf file.

sudo nano /etc/sysctl.cnf

Add the following two lines.

net.core.somaxconn = 20000
net.core.netdev_max_backlog = 65535

Save and close the file. Then apply the settings.

sudo sysctl -p

Two Virtual Host file For the Same Website#

If you run sudo nginx -t and see the following warning.

nginx: [warn] conflicting server name "example.com" on [::]:443, ignored
nginx: [warn] conflicting server name "example.com" on 0.0.0.0:443, ignored

It means there are two virtual host files that contain the same server_name configuration. Don’t create two virtual host files for one website.

PHP-FPM Connection reset by peer#

Nginx error log file shows the following message.

recv() failed (104: Connection reset by peer) while reading response header from upstream

This may be casued by a restart of PHP-FPM. If it’s retarted manully by yourself, then you can ignore this error.

Cloudflare Errors#

Here are some common errors and solutions if your website runs behind Cloudflare CDN (Content Delivery Network).

521 Web Server is Down#

• Nginx isn’t running.
• You didn’t open TCP ports 80 and 443 in the firewall.
• You changed the server IP address, but forgot to update DNS record in Cloudflare.

The page isn’t redirecting properly#

If your SSL setting on the SSL/TLS app is set to Flexible, but your origin server is configured to redirect HTTP requests to HTTPS, Your Nginx server sends reponse back to Cloudflare in encrypted connection. Since Cloudflare is expecting HTTP traffic, it keeps resending the same request, resulting in a redirect loop. In this case, you need to use the Full (strict) SSL/TLS option in your Cloudflare settings.

source: https://www.linuxbabe.com/linux-server/how-to-fix-common-nginx-errors