RackNerd VPS Has No Network: What to Do (2026): Troubleshooting and Fixing SSH and Ping Failures When VNC Works

On your local computer, first run three checks:

ping -c 4 你的VPS公网IP
nc -vz 你的VPS公网IP 22
ssh -vvv root@你的VPS公网IP

A failed Ping alone cannot prove the server is offline; many VPS filter ICMP. What is truly diagnostic is TCP port 22:

If the same machine worked before and you just changed UFW, iptables, NetworkManager, or netplan, prioritize rolling back and checking from the most recent change.

Log in to the provider console's VNC or Web Console, and first check the kernel and network interfaces:

uname -a
ip -br link
ip -br address
ip route

Normally, the main network interface (commonly named eth0, ens3, or enp1s0) should be UP and have a public IPv4 assigned by the provider. The default route usually looks like:

default via 203.0.113.1 dev eth0
203.0.113.0/24 dev eth0 proto kernel scope link src 203.0.113.10

The following results mean, respectively:

• The interface is DOWN: the interface is not enabled, or the network management service has not taken it over;
• The interface is UP but has no inet address: DHCP, static configuration, or cloud-init configuration has a problem;
• It has an IP but no default route: it can only reach the same subnet and cannot access the internet;
• IP and route are both normal but domain names fail: continue checking DNS, do not repeatedly restart the interface.

After confirming the physical interface name, run:

ip link set dev eth0 up

Replace eth0 with the actual name shown by ip -br link. This command only enables the interface; it will not guess the IP and gateway for you.

Do not only run ping google.com. Testing in the following order quickly locates which layer the failure is in:

ip route get 1.1.1.1
ping -c 4 你的默认网关
ping -c 4 1.1.1.1
getent hosts google.com
resolvectl status 2>/dev/null || cat /etc/resolv.conf

• The default gateway cannot be Pinged: first fix the interface, IP, route, or provider-side network;
• Gateway reachable, 1.1.1.1 unreachable: check the default route, egress policy, and the VPS provider's network status;
• 1.1.1.1 reachable, domain names fail: check /etc/resolv.conf, systemd-resolved, or DNS firewall rules;
• All normal but SSH fails: the failure has narrowed down to sshd, the port 22 firewall, or Fail2Ban.

Temporarily test DNS (for diagnosis only; do not permanently override the distribution's DNS management):

resolvectl query google.com 2>/dev/null || nslookup google.com

If it really is a resolution service failure, first check the current configuration, then fix it according to the corresponding method for your system. Do not directly change /etc/resolv.conf into a plain file and use it long-term, because it may be overwritten by netplan, NetworkManager, or systemd-resolved.

Ubuntu Server commonly uses netplan together with systemd-networkd; desktop or some images may also use NetworkManager. First confirm the current status:

systemctl is-active systemd-networkd
systemctl is-active NetworkManager
networkctl status 2>/dev/null | head -n 30
ls -l /etc/netplan/

Check the netplan configuration to confirm the interface name, DHCP, and default route have not been broken:

sudo sed -n '1,200p' /etc/netplan/*.yaml

Back up before modifying, and use netplan try instead of directly using apply. netplan try automatically rolls back after a confirmation timeout, which is suitable for repairing remote networking via VNC:

sudo cp -a /etc/netplan /etc/netplan.backup-$(date +%F-%H%M)
sudo netplan try

If you confirm the configuration is correct, then apply it and check the route:

sudo netplan apply
ip -br address
ip route

Only run this when you confirm the system uses NetworkManager:

sudo systemctl enable --now NetworkManager
nmcli device status
nmcli connection show

Do not force-enable NetworkManager on an Ubuntu image where systemd-networkd is working normally; two services taking over the same interface at the same time may cause route and address conflicts.

Rocky Linux, AlmaLinux, and newer CentOS usually manage networking with NetworkManager. First check the service and connections:

systemctl status NetworkManager --no-pager
nmcli device status
nmcli connection show --active

If NetworkManager is indeed not running and the system has no other network service taking over the interface, you can run:

sudo systemctl enable --now NetworkManager
nmcli device connect eth0
ip -br address
ip route

Likewise, replace eth0 with the real interface name. If the service fails to start, check the logs first; do not restart repeatedly:

sudo journalctl -u NetworkManager -b --no-pager -n 150

Focus on checking whether the connection configuration contains a wrong static IP, gateway, subnet mask, or duplicate default route. The IP, gateway, and mask shown in the RackNerd console should be based on the current instance information; do not copy parameters from someone else's tutorial.

If the gateway and public IP are both reachable but external TCP 22 times out, check the host firewall:

sudo ufw status verbose 2>/dev/null || true
sudo nft list ruleset
sudo iptables -S 2>/dev/null
sudo fail2ban-client status sshd 2>/dev/null || true

Confirm the SSH port is allowed in the current rules. Do not run commands that clear all rules just to "quickly restore." If you must temporarily allow access, first save the existing rules and restrict the source IP. If you lost connectivity right after enabling UFW, refer to the recovery checklist for when SSH is inaccessible after enabling UFW.

If only your own public IP is blocked, check the Fail2Ban ban list and unban a single address:

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 你的公网IP

Do not think the problem is solved after permanently opening SSH to the whole world. After restoring access, you should use key login, restrict management sources, disable password login, and keep VNC or Rescue Mode as the last self-rescue entry point.

After the network is restored, continue confirming the SSH service itself:

sudo systemctl status ssh 2>/dev/null || sudo systemctl status sshd
sudo ss -lntp | grep -E ':(22|2222)'
sudo sshd -t

Only when sshd -t has no output does it mean the syntax check passed. If you modified /etc/ssh/sshd_config, fix the syntax first, then restart the service:

sudo systemctl restart ssh 2>/dev/null || sudo systemctl restart sshd
sudo journalctl -u ssh -u sshd -b --no-pager -n 100

Confirm whether you changed the port to 2222 or another port, and check the cloud firewall and host firewall accordingly. When the service listens on 127.0.0.1 instead of 0.0.0.0, external connections also fail.

If the interface, route, firewall, and sshd are all normal but TCP 22 still times out:

1. In the RackNerd console, confirm the instance is not suspended, overdue, or triggering traffic limits;
2. Check whether the IPv4 shown in the console has changed and whether DNS still points to the old address;
3. Use VNC to check dmesg -T and system logs, confirming there is no full disk, kernel error, or failed startup task;
4. Use Rescue Mode to mount the system disk and fix netplan, sshd, or firewall configuration;
5. Keep the test time, source IP, target IP, Traceroute, and port test results in the ticket to help the provider locate upstream issues.

Basic diagnostic information can be collected like this:

date -Is
ip -br address
ip route
ss -lntp
sudo journalctl -b --no-pager -p warning..alert | tail -n 100

When you need to handle Rescue Mode, chroot, and filesystem checks in depth, refer to How to use VPS rescue mode. Do not run fsck or formatting commands without knowing the disk device.

After confirming SSH is restored, immediately do a minimal hardening:

• Use a normal administrator + sudo, avoiding long-term direct root password login;
• Configure SSH keys for the administrator, and disable password login only after testing that a new session succeeds;
• Keep a verified working VNC or rescue entry point;
• Record netplan / NetworkManager configuration, gateway, and firewall changes;
• Set up monitoring for disk, memory, network, and service status, so failures are not only discovered by users.

When VNC can log in but SSH and Ping fail, it is usually not that "the server is completely dead," but that some layer in the public network link has a problem. The correct order is: confirm the interface and public IP, then check the default route, then distinguish DNS, host firewall, and sshd, and only finally consider the provider upstream or Rescue Mode.

The most important point is not to treat systemctl enable --now NetworkManager as a universal command. First identify the distribution and current network manager, then use netplan try, nmcli, nftables, or systemd logs for targeted repairs, so as to reduce the risk of a second network outage.