Skip to content

DIEG Knowledge Base & IT Tools

dieg@vps-node:~ (ssh)
root@dieg-vps:~# Interactive DevOps / SysAdmin Excuse Generator

# Server crashed and client is calling? Generate a plausible excuse via AI from a remote VPS node

What to do if your server is down or website is unreachable: step-by-step troubleshooting

When a website is unreachable and the web server stops responding to requests, the main goal is to quickly pinpoint the root cause before your business suffers or SEO rankings drop.

Real causes of server and website outages

1. Disk Space or Inode Limit Exhaustion (No space left on device)

The most common cause of hidden server crashes. Full disk capacity is a sneaky issue: it rarely reports itself directly and instead triggers a cascade of “phantom” errors across the entire operating system:

  • Databases (MySQL / PostgreSQL): Authentication failures, abrupt shutdowns of mysqld / postgres services due to inability to write WAL logs, transactions, or temporary tables.
  • Web Servers (Nginx / PHP-FPM): 500 Internal Server Error and 502 Bad Gateway issues, caused by PHP’s inability to save session files or cache.
  • Inodes: Exhaustion of the index node limit (millions of small session files, cache, or logs) even when formal disk space is still available. Inodes are frequently overlooked — your disk might show free space, but the file count limit has been hit.

Diagnostics:

# Check free disk space
df -h
# Check Inode usage
df -iT
# Count Inodes used per folder in the web root directory (/var/www/)
ls -d1 /var/www/* | while read i; do echo -en "$i\t"; find "$i" -name "*" | wc -l; done;
# Alternatively using du (specifically designed to track down directories consuming Inodes)
du --inodes -x --max-depth=1 /var/www/ | sort -n

2. OOM Killer Triggered (Out of Memory, Killed)

Running out of RAM is a classic scenario. The Linux kernel kills memory-heavy processes to prevent a total system crash. OOM can also occur when a process control group hits its memory limit via cgroups, even if host RAM is still available. For diagnostics, check kernel logs for these key patterns:

# Kernel messages for the last 24 hours on systemd-based hosts
sudo journalctl -k --since "24 hours ago" --no-pager |
  grep -Ei 'out of memory|oom-kill|killed process'

# Alternative: inspect current kernel ring buffer
sudo dmesg -T | grep -Ei 'out of memory|oom-kill|killed process'

# Current RAM and swap memory usage
free -h

3. Expired SSL Certificate (Certificate expired, Certificate verify failed)

The server is running fine, but browsers display security warnings when visitors access the site, while automated API scripts fail with SSL error: certificate verify failed or error: certificate has expired. Primary causes include:

  • Certbot / Let’s Encrypt renewal cron job failed to execute.
  • Incomplete intermediate certificate chain (missing CA Bundle).
  • The VPS hostname matches the domain name in control panels (e.g., FastPanel), causing /etc/hosts to loop the domain back to 127.0.0.1.

To test SSL certificate renewal routines for certs already managed by Certbot without applying changes:

sudo certbot renew --dry-run

4. Incorrect AAAA Record: Website Unreachable via IPv6

Common configuration issues leading to IPv6 failures:

  • The AAAA record points to an incorrect or outdated IPv6 address.
  • The IPv6 address is valid in DNS but not assigned to the network interface.
  • The web server is not listening on IPv6 sockets on ports 80/443.
  • Firewall rules allow IPv4 traffic but drop IPv6 packets.

Diagnostics (replace example.com with your actual domain name):

# Query published AAAA records in DNS
dig +short AAAA example.com

# Test HTTP/HTTPS response over IPv4
curl -4 -I --connect-timeout 10 https://example.com/

# Test HTTP/HTTPS response over IPv6
curl -6 -I --connect-timeout 10 https://example.com/

Note: IPv6 diagnostic commands must be executed from a client computer or VPS node with an active IPv6 connection.