VPS Lost Network After a Netplan Edit? Fix Static IP Config

You edited /etc/netplan/*.yaml to set a static IP, ran netplan apply, and now SSH just hangs. If that's you, don't panic — this is one of the most common ways to lock yourself out of a fresh Ubuntu VPS, and it's almost always fixable through the console in a couple of minutes.

Symptom

A few variations of the same problem, all from the same root cause:

• SSH connection times out right after you ran netplan apply
• The VPS pings but SSH refuses the connection, or vice versa
• You applied a static IP and now the server has no internet access at all — DNS lookups and outbound pings both fail
• The VPS boots fine but the interface never comes up, so it doesn't even get an IP

None of this means the server is dead. Netplan just applied a network config that doesn't match reality, and the box is sitting there with no route out.

Cause

Netplan (Ubuntu's default network configuration frontend since 18.04, sitting on top of either systemd-networkd or NetworkManager) is YAML, and YAML is unforgiving. The usual culprits, roughly in order of how often we see them:

1. Wrong interface name

Cloud images don't always use eth0. Depending on the provider and kernel, it might be ens3, enp1s0, or something else entirely. If your netplan file references an interface that doesn't exist on this box, the config silently does nothing — no error, no IP, no network.

Check the real name first:

ip a

Whatever shows up with your MAC address and is currently UP (even without an IP) is the one netplan needs to reference.

2. Missing or wrong gateway

A static IP without a correct gateway4 (or a routes entry, on newer netplan syntax) leaves the box able to receive on its LAN segment but with no way to send packets anywhere else. This is the classic 'pings locally, nothing external works' case.

3. Indentation errors

YAML uses whitespace to define structure, and netplan is strict about it. Tabs instead of spaces, a stray extra space, or a list item aligned wrong will either make netplan apply throw a syntax error or, worse, get silently ignored on apply while systemd-networkd falls back to whatever config it had before (which might be nothing).

4. Forgot to disable cloud-init's network config

On many cloud VPS images, cloud-init manages networking by default and writes its own netplan file on every boot, overwriting your manual edits. If your changes keep reverting after a reboot, this is almost certainly why.

Fix

Step 1: Get console access

Since SSH is down, you need out-of-band access. Every major VPS provider offers a browser-based console (sometimes called VNC console, serial console, or 'recovery console') in their dashboard — log in there first. This works even with zero network connectivity because it talks to the VM directly, not over the network.

Step 2: Check the current netplan config

cat /etc/netplan/*.yaml

A correct static IP config on a typical single-NIC Ubuntu VPS looks like this:

network:
  version: 2
  ethernets:
    eth0:
      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]

Older netplan versions use gateway4: 203.0.113.1 instead of the routes block — both work, but don't mix them; newer netplan (0.106+, shipped with 22.04 and later) warns or errors if you set both.

Step 3: Validate the YAML before applying

Never run netplan apply blind on a config you just edited. Use the built-in dry-run first:

sudo netplan try

netplan try applies the config, waits 120 seconds for you to confirm it worked, and automatically reverts if you don't confirm — which is exactly the safety net you want when you're one typo away from losing SSH. If you're already in the console and can't use SSH to confirm, just run:

sudo netplan apply
ip a
ip route

and check the interface actually picked up the address and default route.

Step 4: Confirm the interface name matches

If ip a from Step 1 showed ens3 but your YAML says eth0, fix the block key and re-run. This single mismatch causes more lockouts than every other cause combined.

Step 5: Fix cloud-init if it's overwriting your config

If your static IP works until the next reboot and then reverts, disable cloud-init's network management:

sudo tee /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg <<'EOF'
network: {config: disabled}
EOF

Then re-apply your netplan config and reboot to confirm it sticks.

Step 6: Test connectivity properly

ping -c3 1.1.1.1        # tests routing, bypasses DNS
ping -c3 google.com     # tests DNS resolution
ip route get 1.1.1.1    # shows which route/interface would be used

If the first ping fails but the interface shows an IP, it's a gateway/route problem. If the first works but the second doesn't, it's DNS (check nameservers in the same netplan block, or /etc/resolv.conf if you're on systemd-resolved).

Prevention

If you manage a Getwebup VPS and end up fully locked out with no console access working either, open a support ticket with your VM's ID — we can pull console logs and, if needed, boot into a recovery environment to fix the netplan file directly.