VPS Troubleshooting Guide 2026: Fix Down, Slow, or Broken Servers

1. The Troubleshooting Mindset

Before you type a single command, remember three rules that separate fast fixes from hours of panic:

1. Don't change multiple things at once. One edit, one test, one observation. Changing Nginx config and restarting php-fpm and rebooting all at once means you will never know which thing fixed it - or broke it further.
2. Read logs before restarting services. Restarting clears the evidence. Grab the tail of the error log first: the last 50 lines almost always tell you exactly what is wrong.
3. Recall your last change. 80% of outages are self-inflicted. What did you deploy/edit/restart in the last hour? That is where to look first. Check history | tail -50 if you forgot.

Keep a runbook file (even a simple text note) with your own common commands. When something breaks at 3 AM, you will not remember syntax.

2. The Diagnosis Decision Tree

Start with this binary tree. It eliminates 80% of possibilities in under two minutes.

Figure 1: Binary decision tree - follow it top to bottom on any outage

Run these four commands in order, and you will know which section of this article to jump to:

# Step 1: Is the server reachable at all?
ping -c 4 YOUR_SERVER_IP
mtr -rw YOUR_SERVER_IP

# Step 2: Can you SSH in?
ssh root@YOUR_SERVER_IP

# Step 3: Does the web respond?
curl -I https://yoursite.com

# Step 4: What do the logs say?
journalctl -xeu nginx --since "10 min ago"

3. Issue 1: Server Completely Unreachable

When ping doesn't respond and SSH times out, the problem is at the network or hypervisor level.

Check in order:

1. Is the VPS powered on? Check your provider panel. Accidental shutdowns and suspended billing are common.
2. Did you enable UFW and forget to allow SSH? This is the #1 self-inflicted outage. Fix via VNC console: ufw allow 22/tcp then ufw reload.
3. Is there a DDoS attack? Check provider's network status page. If your IP is being targeted, ask for a new IP or enable DDoS protection. US-based VPS with DDoS protection is worth considering if this happens regularly.
4. Did you change network config? A wrong /etc/network/interfaces or Netplan config will disconnect you. Fix via VNC console.
5. Has the kernel panicked? Check via VNC - if you see a frozen console with kernel messages, the only fix is a reboot (and then check /var/crash or dmesg after boot for clues).

4. Issue 2: SSH Connection Refused

"Connection refused" means the IP is reachable but nothing is listening on port 22 (or your SSH port). "Connection timed out" is a firewall/network issue - different problem.

# Log in via VNC console, then:
systemctl status sshd
ss -tulpn | grep :22
ufw status
# If sshd is stopped:
systemctl start sshd
systemctl enable sshd
# If port 22 is blocked by firewall:
ufw allow 22/tcp
ufw reload
# If you changed SSH port in sshd_config, check:
grep Port /etc/ssh/sshd_config

5. Issue 3: 502 / 503 / 504 Bad Gateway

HTTP errors tell you where the problem is. Different codes mean different layers.

Figure 2: Each error code points to a specific layer - read the log at that layer

# The fastest 502/504 diagnosis:
systemctl status php8.2-fpm    # or whatever PHP version you run
tail -50 /var/log/nginx/error.log
tail -50 /var/log/php8.2-fpm.log
# Common fix - restart php-fpm:
systemctl restart php8.2-fpm
# Check if socket path matches Nginx config:
grep fastcgi_pass /etc/nginx/sites-available/*
ls /run/php/

6. Issue 4: High CPU / Server Slow

A slow site is often a runaway process. Identify it first, then kill or optimize.

# See what's using CPU - press F6 to sort by CPU%:
htop
# If htop isn't installed:
apt install htop -y
# Quick top-5 CPU hogs (non-interactive):
ps aux --sort=-%cpu | head -6
# Check system load averages:
uptime
# Check for suspicious processes (cryptominer malware):
ps aux | grep -E 'minerd|kworkerds|xmrig'
chkrootkit    # install if needed: apt install chkrootkit

Load averages above your vCPU count for sustained periods mean the server is overloaded. A 2-vCPU VPS with load of 6.0 means three tasks are waiting for CPU at any given moment - that's when you see timeouts.

7. Issue 5: Out of Memory (OOM) Kills

When RAM is exhausted, Linux's OOM Killer shoots processes to keep the kernel alive. You'll see random services die - usually MySQL or php-fpm because they use the most memory.

# Check if OOM killer struck recently:
dmesg | grep -i "killed process"
# Shows last 24 hours of OOM events:
journalctl -k --since "24 hours ago" | grep -i oom
# Current memory usage:
free -h
# Find memory hogs:
ps aux --sort=-%mem | head -8

Fixes in order of effectiveness:

1. Add swap space (prevents sudden OOM kills, even if slow): fallocate -l 2G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile
2. Tune php-fpm: Reduce pm.max_children - too many children = memory exhaustion. Calculate: total RAM / average process size = max children.
3. Install earlyoom: apt install earlyoom - it kills memory hogs before the kernel panics and hangs.
4. Tune MySQL/MariaDB: Large innodb_buffer_pool_size on small VPS causes OOM. Set it to 40-50% of available RAM on 1-2GB servers.
5. Upgrade RAM - if all else fails, move to a higher-tier VPS.

8. Issue 6: Disk Full

A full disk causes silent failures everywhere: MySQL can't write, Nginx can't cache, SSL renewal fails, logs stop recording - making the problem harder to diagnose (no logs!).

# See which partition is full:
df -h
# Find which directories are using the space:
du -sh /* | sort -hr | head -10
# Common culprit 1: Systemd journals
journalctl --vacuum-size=200M
# Common culprit 2: Docker images and volumes
docker system df
docker system prune -a
# Common culprit 3: Old logs in /var/log
du -sh /var/log/*
find /var/log -name "*.gz" -delete    # delete rotated compressed logs
# Common culprit 4: Old backups in /tmp or /root
ls -lhS /tmp /root | head

9. Issue 7: SSL Certificate Errors

Browser warnings like "Your connection is not private" usually mean an expired or wrong certificate.

# Check certificate expiration on your server:
certbot certificates
# Renew manually:
certbot renew
# If renewal fails, check:
# 1) Port 80 is open (http-01 challenge needs it)
ufw status
# 2) Nginx serves .well-known directory correctly
# 3) DNS points to THIS server (not old IP after migration)
dig +short yoursite.com
# Check if renewal timer is active:
systemctl list-timers | grep certbot

10. Issue 8: Emails Not Sending

This is the single issue that catches new VPS users by surprise. Most VPS providers block outbound port 25 by default to prevent spam. You will spend hours debugging Postfix and it will never work - it's blocked at the ISP level.

Figure 3: Quick reference - match your symptom, run the first command

The solution is not to fight port 25. Use a transactional email service:

• Resend - 3,000 emails/month free, developer-friendly API
• Postmark - Great deliverability, $10/month for 10,000 emails
• Mailgun / SendGrid - Generous free tiers
• SMTP.com / Mailpit for testing

You also need SPF, DKIM, and DMARC records in DNS for email to reach inboxes (not spam folder). A transactional service handles all of this for you.

11. Incident Response Timeline

When something is on fire, you need a procedure, not panic. Follow this order:

Figure 4: Four phases of incident response - from triage to prevention

1. 0-5 minutes: Stop the bleeding. If the site is down, enable a maintenance page or roll back the last deploy. Don't try to diagnose while users see errors.
2. 5-15 minutes: Identify root cause. Work through the decision tree in section 2. Read logs. Check resources. Find what changed.
3. 15-60 minutes: Apply the fix. One change at a time. Test after each change. If a restart fixes it, you haven't fixed the root cause - you've delayed the next outage.
4. 1-24 hours: Prevent recurrence. Add monitoring. Fix the backup. Write a short post-mortem (what happened, why, what you changed, how to detect it next time). Update this checklist.

12. Preventing Future Outages

The best troubleshooting is avoiding the problem entirely. These 8 preventive steps will eliminate the majority of incidents:

Figure 5: Implement these before your next outage - high priority items first

1. Set up monitoring and alerts. CPU, memory, disk, HTTP status, and SSL expiration should all page you before they cause outages. See Netdata + Uptime Kuma guide.
2. Automate backups and test restores. An untested backup is not a backup. See the VPS backup strategy guide for Restic/Borg setup and quarterly restore testing.
3. Enable fail2ban and UFW. Block SSH brute force, close unused ports. See VPS security hardening checklist.
4. Install earlyoom to prevent OOM hangs.
5. Configure logrotate (usually automatic, but verify with logrotate -d /etc/logrotate.conf).
6. Add swap space as a safety net (2GB is plenty for most small VPS).
7. Document your setup. A simple markdown file in your home directory with common commands is worth gold during a panic.
8. Test your backups quarterly. Actually spin up a test VPS and restore from backup. You might be surprised what doesn't work.

If you're currently troubleshooting a VPS issue and finding that underlying hardware problems (constant CPU steal, I/O timeouts, network drops) are the root cause - those are provider problems no amount of configuration fixes. A reliable VPS provider with honest resource allocation eliminates an entire class of headaches. See our VPS plans starting at $8.80/month with KVM virtualization, NVMe SSD, and a 99.9% uptime SLA.

Frequently Asked Questions