Skip to content
Troubleshooting Terminal Required 14 min read

Common Server Troubleshooting Steps

A practical workflow for checking uptime, logs, resource usage, services, and network ports when something breaks on your server.

When a site is slow, unreachable, or returning errors, a structured troubleshooting approach saves time and prevents unnecessary changes. This guide walks through the checks SerVee IT engineers use first on Linux web servers running Apache or NGINX with PHP and MySQL/MariaDB.

Confirm the Symptom

Before changing configuration, document exactly what fails: browser error code, affected URLs, whether the issue is global or limited to one domain, and when it started. Test from more than one network (mobile data vs office Wi‑Fi) to rule out local DNS or ISP problems.

Check HTTP Status and Response

From your workstation or the server, request the site and inspect headers and body:

curl -I https://example.com
curl -sS -o /dev/null -w "%{http_code} %{time_total}\n" https://example.com/

Compare HTTP vs HTTPS. A redirect loop often shows as 301/302 chains; a dead backend may return 502 or 504. See the MDN HTTP status reference for code meanings.

Verify DNS and Connectivity

Confirm the domain resolves to the expected IP and that ports 80 and 443 are reachable:

dig +short example.com A
dig +short www.example.com A
nc -zv YOUR_SERVER_IP 443

If DNS is wrong, fix records at your registrar or DNS provider (e.g. Cloudflare DNS) before debugging the web stack.

Check Web Service Status

On the server, confirm the web server and PHP-FPM (if used) are running:

# Apache (RHEL/Alma/Rocky/CentOS-style)
sudo systemctl status httpd

# NGINX
sudo systemctl status nginx

# PHP-FPM (version may vary)
sudo systemctl status php-fpm

Restart only after identifying a clear failure; document the prior state. Official references: Apache HTTP Server documentation, NGINX documentation.

Warning: Restarting services during peak traffic can drop active connections. Schedule restarts when possible and use graceful reload where supported (systemctl reload httpd or nginx -s reload).

Review Error Logs

Logs usually pinpoint the failing layer. Typical locations:

  • Apache: /var/log/httpd/error_log or /var/log/apache2/error.log
  • NGINX: /var/log/nginx/error.log
  • PHP-FPM: /var/log/php-fpm/www-error.log (path varies by distro)
  • MySQL/MariaDB: /var/log/mysqld.log or journal via journalctl -u mysqld
sudo tail -n 100 /var/log/nginx/error.log
sudo journalctl -u php-fpm --since "1 hour ago" --no-pager

Disk, Memory, and Load

Full disks and exhausted memory cause 500 errors, failed uploads, and database crashes:

df -h
free -h
uptime
dmesg | tail -n 20

Clear old logs and temporary files only after confirming they are safe to remove. Rotate logs via logrotate rather than deleting active files held open by daemons.

Tip: On WordPress hosts, oversized wp-content/debug.log or backup plugin folders are frequent causes of full partitions.

Database and Application Layer

For CMS sites, verify database connectivity and credentials in the application config. On WordPress, a white screen often ties to PHP fatal errors—enable logging without displaying errors to visitors (see our WordPress debugging guide).

mysql -u DB_USER -p -e "SELECT 1;"
mysql -u DB_USER -p DB_NAME -e "SHOW TABLES LIMIT 5;"

SSL and Firewall

Certificate expiry and firewall rules block HTTPS and admin ports:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates
sudo firewall-cmd --list-all 2>/dev/null || sudo iptables -L -n

Renew certificates via your ACME client or control panel before they expire. Let's Encrypt documentation covers automated renewal.

Recent Changes

Correlate the incident with deployments: DNS updates, PHP version changes, plugin updates, .htaccess edits, or firewall changes. Roll back one change at a time and retest.

Summary

Effective server troubleshooting starts with a clear symptom, then validates DNS, service health, logs, resources, database connectivity, and SSL. Work top-down from the network to the application, change one variable at a time, and keep notes for post-incident review. SerVee IT clients with managed support can open a ticket with curl output, log excerpts, and timestamps to speed resolution.