Troubleshooting a server you cannot reach

Do these in order. Each step rules out a layer.

1. Is it running?

Check the server's page in the portal. The status tile says running, stopped, or suspended.

• Stopped: start it from the same page.
• Suspended: this is a billing suspension. Add credit and it comes back automatically. See Low credit and suspension.
• Running: carry on.

2. Can you get in through the browser console?

Open the browser console. It attaches to the virtual display, so it works even when the network stack, SSH and the firewall are all broken.

• Console shows a login prompt: the server is fine and the problem is network or SSH. Go to step 3.
• Console shows kernel messages, a boot loop, or nothing: the problem is inside the server. Go to step 5.

3. Is the network up inside the server?

From the console:

ip -brief address
ip route
ping -c 3 1.1.1.1

• No address on the interface: the network configuration was changed. Look at /etc/netplan/ or /etc/sysconfig/network-scripts/.
• Address present but no route: the default gateway is missing.
• Ping works: outbound is fine, so this is inbound filtering or a service problem.

4. Is the service listening, and is it filtered?

sudo ss -tulpn

You are looking for your port bound to 0.0.0.0 or ::. Bound to 127.0.0.1 means it is only reachable from inside the server, which is a very common cause of "the port is closed".

Then check the LayerOne cloud firewall on the Networking tab. If the inbound policy is DROP and there is no rule for the port, that is your answer. And check any firewall running inside the server too:

sudo ufw status          # Debian, Ubuntu
sudo firewall-cmd --list-all   # Rocky, Alma

5. Is the disk full?

The single most common cause of a server that boots but does nothing useful.

df -h
df -i          # inodes; can run out while space remains
du -xh / 2>/dev/null | sort -h | tail -30

Usual culprits: /var/log, Docker images, an application log with no rotation.

sudo journalctl --vacuum-size=200M
docker system prune -a

6. Is it out of memory?

free -h
dmesg -T | grep -i 'killed process'

An oom-kill line names what was killed. Fix it by adding swap, capping the process, or moving to a larger plan. See Resize to a larger plan.

7. Is something failing to start?

systemctl --failed
journalctl -p err -b --no-pager | tail -50
journalctl -u yourservice -n 100 --no-pager

8. Is it us?

Check the status page for an incident on your location, and use the looking glass to test the path from our network to yours. An mtr in both directions is what makes a routing problem provable:

mtr --report --report-cycles 20 your.home.ip.address

Still stuck

Open a ticket with the instance id and the output of whichever steps above were interesting. What makes this fast for us:

• The instance id or its IP address
• ss -tulpn, df -h, free -h
• journalctl -u yourservice -n 50 --no-pager
• mtr --report in both directions for anything network related
• The exact error, copied rather than described

The last resort

Reinstalling gives you a clean server on the same IP address in a few minutes, and erases the disk completely. It is often faster than debugging a server you were going to rebuild anyway, but only if you have your data somewhere else first.