If the VPS has no network access (can't ping out, can't be reached), work through:
Is it the OS or the network? Open the web console. If the OS is responsive but ping 1.1.1.1 fails from the console, the issue is network config or firewall — not the OS.
Firewall locked you out? This is the #1 cause. From the web console, flush or disable the firewall temporarily:
sudo ufw disable # if using ufwsudo iptables -F # if using iptables (flushes all rules)
Then restore access and re-apply rules carefully.
Wrong interface name? Some templates use ens3 or enp1s0 instead of eth0. Run ip link to confirm before editing netplan or interfaces files.
Always have the web console open before changing firewall or network settings. A bad rule can drop your SSH session instantly.
If the server is reachable but slow or dropping packets:
mtr -rwzbc 100 1.1.1.1
Read the mtr output:
Loss at the first hop (your VPS) — local issue: load, firewall, or config.
Loss only in the middle — a transit provider between you and vps.direct; often outside our control.
Loss at the destination — the remote network, not yours.
Compare with the Looking Glass results from the vps.direct side. If the loss starts at your VPS's own gateway, open a ticket with the mtr output.
A few percent loss at a single middle hop is often just rate-limited ICMP and not real packet loss for your traffic. Watch the final destination's loss rate — that's what matters.
If ping 1.1.1.1 works but ping google.com fails, DNS is the problem:
cat /etc/resolv.confnslookup google.com
Fix it by setting a working resolver:
sudo nano /etc/resolv.conf
nameserver 1.1.1.1nameserver 8.8.8.8
On systemd-resolved systems, /etc/resolv.conf is a symlink that gets overwritten. Use sudo resolvectl dns eth0 1.1.1.1 8.8.8.8 instead, or configure the resolver in your netplan file.
If IPv6 is in your service details but isn't working:
Confirm the address is assigned: ip -6 addr show
Confirm the route: ip -6 route show default
Test: ping6 -c 4 ipv6.google.com
Use the exact address, prefix, and gateway from your service details. If IPv6 is missing entirely from your service details, it may not be included on your product/location — open a ticket to confirm.
If the VPS is online but a service isn't reachable:
ss -tlnp | grep <port> # is the service listening?sudo ufw status # is the port allowed?
Check both the in-OS firewall and the control panel firewall. A service that isn't listening (ss shows nothing) is an application problem, not a network problem.
