“The site is down”, “I can’t connect to the database”, “downloads are slow”: network problems are easiest to solve by working bottom-up, one layer at a time, with a quick test at each step. This checklist works for VPS and dedicated servers alike, and points to deeper guides for each tool.

If SSH itself doesn’t work, use your provider’s VNC console to run these checks from the server side.

1. Is the interface up and does it have its address?

ip -br link                 # UP / DOWN per interface
ip -br addr                 # IPv4/IPv6 addresses

Expect the public interface (eth0, ens3…) to be UP with the server’s IP. A missing address usually means a network config error after an edit or upgrade. Check netplan (/etc/netplan/*.yaml) or /etc/network/interfaces, then apply. See ip command and netplan.

2. Is there a default route?

ip route
# default via 203.0.113.1 dev eth0 …
ping -c 3 203.0.113.1       # the gateway (may not answer ICMP on some networks)

No default route means no internet. Restore the gateway in the network config.

3. Can you reach the internet by IP?

ping -c 3 1.1.1.1
ping -c 3 8.8.8.8

If this works, routing to the internet is fine. If it fails while the interface and route look right, check the firewall’s outbound rules and contact your provider (possible network issue).

4. Does DNS work?

getent hosts example.com
dig +short example.com
resolvectl status            # which DNS servers are configured (systemd-resolved)
cat /etc/resolv.conf

If IPs work but names don’t, fix the resolvers. See change DNS servers and dig.

5. Is the service listening?

For “nobody can reach my site or port” problems:

sudo ss -tlnp | grep -E ':80|:443'
sudo ss -ulnp                          # UDP services
systemctl status nginx

Check the address: 127.0.0.1:3306 is reachable only locally, while 0.0.0.0:443 or [::]:443 covers all interfaces. A service bound to localhost is the most common reason “it works locally but not from outside”. See ss and netstat.

Test locally first:

curl -I http://127.0.0.1
curl -I https://example.com --resolve example.com:443:127.0.0.1

6. Is the firewall allowing it?

sudo ufw status verbose
sudo nft list ruleset | less
sudo iptables -L -n -v

Remember Docker’s iptables rules (published ports bypass UFW) and any provider-level firewall or security group in front of the server. See UFW and check open ports.

7. Test from outside

From your computer or another server:

nc -zv 203.0.113.10 443                   # TCP port reachable?
curl -vI https://example.com              # full HTTP/TLS check
nmap -Pn -p 22,80,443 203.0.113.10        # several ports at once
  • Connection refused: the packet arrived, but nothing listens (or a REJECT rule).
  • Timeout: packets are dropped by a firewall on the way, or the route is broken.

See netcat, curl and nmap.

8. Path quality: latency and loss

mtr -rwc 100 example.com           # from server to destination
mtr -rwc 100 203.0.113.10          # from client to server (run on the client)

Loss that starts at one hop and continues to the destination points to a real problem there. Loss only at intermediate hops is usually ICMP rate limiting and harmless. See ping and mtr and packet loss troubleshooting.

9. Throughput

iperf3 -c other-server -t 20          # between two servers you control
speedtest                             # to public test servers

See iperf3. Slow over long distances only? Consider TCP BBR.

10. Look at the packets

When nothing else explains it:

sudo tcpdump -i eth0 -nn port 443 and host 198.51.100.7

Do SYNs arrive? Do SYN-ACKs leave? Do resets appear? See tcpdump.

Special cases

Symptom Look at
Connections establish, then hang on large transfers MTU / PMTU black hole. See MTU explained
Works by IP, not by hostname DNS (step 4), or the web server’s server_name
Works on IPv4, not IPv6 (or vice versa) AAAA records, IPv6 firewall, the service not listening on [::]. See IPv4 vs IPv6
Intermittent timeouts under load conntrack table full (dmesg), file descriptor limits, backlog. See sysctl tuning and ulimit
Only some users affected Their ISP’s route or DNS cache. Ask for an mtr from their side
Outbound SMTP blocked Port 25 policy. Check with nc -zv smtp.gmail.com 25

Quick checklist

1. ip -br addr            → interface UP with IP?
2. ip route               → default route?
3. ping 1.1.1.1           → internet by IP?
4. dig example.com        → DNS?
5. ss -tlnp               → service listening on the right address?
6. ufw/nft/iptables       → firewall allows it?
7. nc / curl from outside → reachable?
8. mtr                    → path quality?
9. iperf3                 → throughput?
10. tcpdump               → what's really on the wire?

Related: SSH connection refused and Linux rescue mode.

  • Networking
  • Linux
  • Troubleshooting