You rebooted the VPS — maybe after a kernel update, maybe just routine maintenance — and now SSH won't connect. No timeout after a long wait, just an immediate connection refused, or nothing at all. The provider's status page says the node is up. Ping to the IP fails too. If you've just spent ten minutes trying the same ssh root@your-ip command hoping it was a fluke, this one's for you.
Symptom
Before reboot, everything worked. After reboot:
- SSH connections refuse or hang indefinitely
- Ping to the VPS's public IP gets no response
- The provider's VNC/web console still boots into a login prompt fine
- Once you're in via console and run
ip a, the expected interface either has no IP address, or has the wrong one
That last point is the giveaway. The server itself is fine — it's the network interface that came up broken, or didn't come up at all.
Why This Happens
On modern Ubuntu (18.04+) and most current Debian-based VPS images, network config is handled by Netplan, which reads YAML files under /etc/netplan/ and hands the actual work off to either systemd-networkd or NetworkManager. A few things commonly break this on reboot:
1. The interface name changed
Interface names like eth0, ens3, and enp1s0 aren't guaranteed to stay the same across a reboot, a kernel upgrade, or a provider-side hardware/hypervisor change. If your netplan file hardcodes eth0 and the kernel now enumerates the NIC as ens3, netplan applies a config to an interface that no longer exists — and the actual live interface gets nothing.
2. A bad edit that was never actually tested
Someone (maybe past-you) edited the netplan YAML to add a static IP, fix a route, or add a second NIC, then ran netplan apply without testing it — and it worked at the time because the *existing* connection didn't need to renegotiate. The broken part only shows up on the next cold boot, when the interface has to come up from scratch using that config.
3. YAML indentation errors
Netplan YAML is whitespace-sensitive. Two spaces vs four, a tab that snuck in from copy-pasting, a missing dash before a list item — any of these can make netplan silently fall back to a broken or empty config, sometimes without throwing an obvious error until you actually reboot.
4. Static IP config conflicting with DHCP
If dhcp4: true and a static addresses: block are both present, or the gateway/route section references an old IP range from a previous static-IP setup, the interface can come up with an address that doesn't match your provider's actual network — which looks identical to "no network" from the outside.
The Fix
You'll need out-of-band access since SSH is down — use your VPS provider's web console / VNC / KVM-over-IP feature to log in locally first.
Step 1: Check what interface actually exists
ip aNote the real interface name (commonly eth0, ens3, enp1s0, or enp0s3 depending on the hypervisor). Compare it against what's written in your netplan file.
Step 2: Find and review the netplan config
ls /etc/netplan/
cat /etc/netplan/*.yamlA typical static-IP config looks like this:
network:
version: 2
renderer: networkd
ethernets:
ens3:
dhcp4: no
addresses:
- 203.0.113.10/24
routes:
- to: default
via: 203.0.113.1
nameservers:
addresses: [8.8.8.8, 1.1.1.1]Check three things: the interface name matches Step 1's output, the indentation is consistent (spaces only, never tabs), and the IP/gateway actually belong to the subnet your provider assigned.
Step 3: Fix the interface name (the most common cause)
If the name in the YAML doesn't match reality, correct it to whatever ip a showed. Save the file.
Step 4: Test before you commit
Don't just run netplan apply blind — use netplan try instead:
sudo netplan tryThis applies the config immediately but automatically reverts after 120 seconds unless you press Enter to confirm. If your fix is wrong and it drops your console session too, it rolls itself back — you're not left stuck.
Step 5: Confirm and apply for real
Once netplan try comes up clean and you can see a correct IP with ip a, confirm it (press Enter), or run:
sudo netplan applyThen verify connectivity from outside — a fresh SSH attempt from your machine, not just a ping from within the console session.
File permissions gotcha
Netplan is picky about who can read its config files. If you created the YAML by hand and it's world-readable, you'll sometimes see a warning and netplan will refuse to apply it correctly:
sudo chmod 600 /etc/netplan/*.yamlPrevention
| Practice | Why it helps |
|---|---|
Always use netplan try, never a raw apply, for config changes | Auto-reverts a bad config before you're locked out |
Keep a copy of a known-working netplan YAML outside /etc/netplan | Gives you something to diff against or restore from console |
| Note your provider's console/VNC access method somewhere you'll remember | You'll need it the moment SSH is unreachable |
Avoid hardcoding interface names when possible — use match: by MAC address instead | Survives interface renaming across reboots and hardware changes |
| Reboot once after any network config change, in a maintenance window | Catches "works until next boot" bugs on your schedule, not 3am |
That last row matters more than it looks. A netplan change that works without a reboot can still be silently broken for the next cold start — the only way to know for sure is to actually reboot and confirm SSH comes back on its own.
Frequently Asked Questions
My VPS provider doesn't offer a web console — how do I fix this?
Check your control panel again under names like "VNC," "KVM console," "Remote console," or "Recovery mode." Nearly every VPS provider offers some form of out-of-band access, even if it's not obvious. SkyServer VPS plans include a browser-based console under the VPS management panel for exactly this situation. If you genuinely have none, open a support ticket — most providers can boot you into a rescue environment on request.
Why did this only happen after a reboot and not right when I edited the config?
Because the live network connection doesn't tear down and rebuild itself just from a config file edit or even a service restart in some cases — it keeps using the already-negotiated state. A full reboot is often the first time the new config actually gets exercised from a cold state, which is exactly why testing with netplan try and then rebooting once matters.
Can I just switch back to the old /etc/network/interfaces style instead of netplan?
On Ubuntu 18.04 and later, netplan is the supported layer and mixing it with the legacy ifupdown style tends to create more confusion, not less. It's better to get the netplan YAML correct — it's a small, learnable format once you've hit this issue once.
What if ip a shows the correct interface with the correct IP, but I still can't connect?
At that point the network stack is fine and the problem has moved elsewhere — check the firewall (ufw status or iptables -L) for a rule blocking port 22, confirm sshd is actually running with systemctl status ssh, and check your provider's network-level firewall/security group settings, which are separate from anything configured inside the VPS.
Is it safe to use DHCP instead of a static IP to avoid all this?
For most VPS setups, yes — if your provider assigns and reserves the same IP to your instance regardless, DHCP removes the whole class of "I typed the wrong static IP" errors. Static IPs matter more when you're running your own routing, multiple IPs on one VPS, or specific firewall/VLAN setups. If you don't have a specific reason to hardcode it, DHCP is one less thing that can go wrong on reboot.
