Web Server Troubleshooting: How to Find and Fix Errors

A web server is responsible for processing HTTP/HTTPS requests and delivering website content to users. If a website becomes unavailable, works slowly, returns 4xx/5xx errors, or periodically stops responding, it is necessary to determine the cause of the issue.
Web server troubleshooting is a systematic diagnostic process that helps identify the problematic component and resolve the issue without making unnecessary configuration changes.

What Are the Most Common Problems?

The most common web server problems include:

• the website is completely unavailable;
• 403, 404, 500, 502, or 504 errors;
• slow website performance;
• the web server fails to start;
• HTTPS or the SSL certificate does not work;
• high CPU or RAM usage;
• insufficient disk space;
• PHP-FPM or another backend stops responding;
• a large number of requests creates excessive server load.

The main troubleshooting rule is: first determine the cause of the problem, and only then modify the configuration or restart services.

1. Check Server Availability

First, make sure that the server is accessible over the network:
ping SERVER_IPHowever, no response to ping does not always mean that the server is unavailable — ICMP traffic may be blocked by the firewall.
Therefore, TCP ports should also be checked:
nc -zv SERVER_IP 80
nc -zv SERVER_IP 443or:
nmap -p 80,443 SERVER_IPIf the ports are unavailable, check the firewall, network rules, and the web server status.

2. Check the Web Server Status

The next step is to check whether Nginx or Apache is running.
For Nginx:
systemctl status nginxFor Apache:
systemctl status apache2On AlmaLinux and RHEL, the service is usually called httpd:
systemctl status httpdIf the service is stopped or has failed, check the system journal:
journalctl -u nginx -n 100Pay particular attention to messages containing failed, bind, permission denied, connection refused, and other errors.

3. Check the Configuration

Configuration errors can prevent the web server from starting or applying changes.
For Nginx:
nginx -tFor Apache:
apachectl configtestIf the configuration test is successful, the changes can be applied:
systemctl reload nginxChecking the configuration before restarting or reloading the service is especially important after manually editing configuration files.

4. Analyze Logs

Web server logs help determine exactly what is happening when an issue occurs.
Main Nginx log files:
/var/log/nginx/access.log
/var/log/nginx/error.logFor Apache:
/var/log/apache2/access.log
/var/log/apache2/error.logOn AlmaLinux/RHEL:
/var/log/httpd/access_log
/var/log/httpd/error_logThe latest Nginx errors can be viewed with:
tail -n 100 /var/log/nginx/error.logTo monitor the log in real time:
tail -f /var/log/nginx/error.logDuring troubleshooting, it is preferable to examine the logs at the exact time the problem occurs. This makes it easier to correlate a specific error with website downtime or slow performance.

5. Check the HTTP Response with curl

The curl command can be used to test a website directly and obtain its HTTP status:
curl -I https://example.comCommon status codes:

Code	Meaning
200	Successful request
301/302	Redirect
403	Access denied
404	Page not found
500	Internal server error
502	Backend communication error
503	Service temporarily unavailable
504	Backend timeout

For more detailed diagnostics, use:
curl -v https://example.comIt displays the connection process, TLS handshake, and HTTP request, helping determine at which stage the problem occurs.

6. Check DNS

If the website is unavailable, check where the domain points:
dig example.com AFor IPv6:
dig example.com AAAAYou can also use:
nslookup example.comIf the domain points to an old or incorrect IP address, users will connect to the wrong server.
When Cloudflare or another CDN is used, DNS may return CDN IP addresses. In this case, the connection should be checked separately at both levels: client → CDN and CDN → origin server.

7. Check the SSL Certificate

HTTPS problems can be caused by an expired or incorrectly installed certificate.
The certificate can be checked with OpenSSL:
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer -datesThe command displays the certificate subject, issuer, and validity period.
It is also useful to run:
curl -Iv https://example.comIf the website uses Cloudflare or another CDN, the certificate visible to visitors may differ from the certificate installed directly on the origin server.

8. Check Listening Ports

To determine whether the web server is listening on the required ports:
ss -lntp | grep -E ':80|:443'The output should contain port 80 and/or 443. If port 443 is not present, the web server on this server is not accepting HTTPS connections directly.
In this case, check the Nginx/Apache configuration and the SSL virtual host.

9. Check PHP-FPM and the Backend

For PHP-based websites, it is important to check not only Nginx or Apache. The web server may be working correctly while PHP-FPM is not responding.
For example:
systemctl status php8.3-fpmThe service name depends on the installed PHP version.
Problems with PHP-FPM often result in 502 Bad Gateway or 504 Gateway Timeout errors.
The error.log may contain messages such as:
connect() failed
upstream timed out
connection refused
In this case, check the PHP-FPM status, its socket or TCP port, the number of processes, and available RAM.

10. Check Server Resources

If the website is slow, check system resource usage:
uptime
free -h
top
df -h
df -iThese commands help check CPU load, RAM usage, available disk space, and inode usage.
When the server is under high load, it is important to identify the specific process consuming the resources. It may be Apache, Nginx, PHP-FPM, MariaDB, or the application itself.

11. Check the Firewall

If the web server is running but cannot be reached, check the firewall.
For UFW:
ufw statusFor firewalld:
firewall-cmd --list-allRules may also be configured through iptables or nftables.
Make sure incoming TCP connections to ports 80 and 443 are allowed.
If an external firewall or provider-level network filter is being used, its rules should also be checked.

12. Check the Virtual Host

Sometimes the web server is working correctly, but the wrong website is displayed or a 404 error is returned. This may be caused by an incorrect virtual host configuration.
Check the following:

• domain name;
• server_name in Nginx;
• ServerName and ServerAlias in Apache;
• website root directory;
• presence of website files;
• file permissions;
• PHP configuration;
• SSL configuration.

For example:
server {
server_name example.com;
root /var/www/example.com;
}If root points to the wrong directory, the web server may work correctly while the website returns a 404 error.

13. What to Check for 502 and 504 Errors

502 Bad Gateway and 504 Gateway Timeout errors are often caused by backend problems.
Check the following step by step:

1. Is PHP-FPM running?
2. Is its socket or TCP port accessible?
3. Is there enough available RAM?
4. Are there too many PHP processes?
5. Are scripts taking too long to execute?
6. Is the database available?

To find related messages in the log:
grep -iE "error|timeout|refused|upstream" /var/log/nginx/error.log

14. Check the OOM Killer

If processes are unexpectedly terminated, the cause may be insufficient RAM.
Check kernel messages:
dmesg -T | grep -i "oom\|out of memory\|killed process"Also:
journalctl -k | grep -i oomIf the OOM Killer is detected, determine which process consumed too much memory and check the configuration of PHP-FPM, Apache, the database, and other services.

15. Check for a Large Number of Connections

A large number of simultaneous connections can overload the web server.
Check the overall connection statistics:
ss -sNumber of HTTPS connections:
ss -ant | grep ':443' | wc -lTo identify IP addresses generating the most requests:
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | headThis can help identify excessive activity from individual IP addresses or bots.

Practical Troubleshooting Algorithm

When a website is unavailable, it is useful to check the system in the following order:
DNS → IP → Firewall → ports 80/443 → web server → Virtual Host → PHP-FPM/backend → database → application
This approach makes it easier to quickly identify the layer where the problem occurs and prevents configuration changes from being made blindly.

Main Commands

dig example.com
ss -lntp
systemctl status nginx
nginx -t
journalctl -u nginx -n 100
tail -f /var/log/nginx/error.log
curl -I https://example.com
curl -v https://example.com
free -h
df -h
top
dmesg -T | grep -i oom

Conclusion

Web server troubleshooting should begin with collecting information rather than blindly restarting services or changing the configuration.
Checking DNS, ports, web server status, logs, SSL, PHP-FPM, and system resources makes it possible to systematically isolate the source of the problem.
First determine which layer is causing the issue, and then modify only the component responsible for it. This approach reduces the risk of additional errors and helps restore website availability faster.