Troubleshooting Connectivity - yourlinuxguide.com

This is a how-to page rather than a reference page - a repeatable process to work through top-down when something can't connect, instead of randomly trying fixes. Each step assumes the previous one checked out; stop at the first thing that doesn't.

1. Is the interface up?

ip link show

Look for UP and LOWER_UP in the flags. UP without LOWER_UP usually means an administratively enabled interface with no physical link - a disconnected cable, or a Wi-Fi adapter not associated with any network. See Networking Basics.

2. Does it have an address?

ip addr show

No address (or an 169.254.x.x self-assigned address) means DHCP failed or nothing configured it. Check whether the relevant service is running:

systemctl status NetworkManager
systemctl status systemd-networkd

3. Can it reach its own gateway?

ip route show           # confirm a default route exists
ping -c 4 <gateway-ip>  # the address shown after "default via"

If this fails, the problem is local - a switch, cabling, or Wi-Fi issue - not anything further downstream.

4. Can it reach something outside the local network, by IP?

ping -c 4 8.8.8.8

Pinging a known external IP directly (bypassing DNS) isolates whether routing beyond the local network works at all, independent of name resolution.

5. Does DNS resolve?

dig example.com

If step 4 succeeds but this fails, the problem is specifically DNS, not general connectivity - see DNS and Resolution for the full diagnostic path, including testing an alternate resolver directly with dig @8.8.8.8 example.com to rule out a broken local resolver.

6. Is a firewall blocking it?

If a specific service isn't reachable but general connectivity is fine, check firewall rules on both ends - including the remote server, which may reject traffic that reaches it perfectly well at the network level:

sudo ufw status
sudo firewall-cmd --list-all
sudo nft list ruleset

See Firewalls: iptables and nftables.

7. Is the remote service actually listening?

A connection refused (as opposed to timing out) usually means the target host is reachable but nothing is listening on the expected port - check on the remote machine itself:

ss -tlnp

State   Local Address:Port   Process
LISTEN  0.0.0.0:22           sshd
LISTEN  127.0.0.1:5432       postgres

Note 127.0.0.1:5432 - a service bound only to localhost is invisible from any other machine on the network, which looks identical to a firewall block from the outside but has a completely different fix (rebind the service, or reach it via SSH port forwarding instead of opening it up).

8. Trace the actual path

If everything above looks fine locally but a specific remote destination still fails, traceroute (or the friendlier, continuously-updating mtr) shows where along the route packets stop getting through:

traceroute example.com
mtr example.com

9. Check the application layer directly

Once raw connectivity is confirmed, a failure might be one layer up - an HTTP error, a TLS certificate problem, or an application timeout rather than a networking issue at all:

curl -v https://example.com

-v shows the full request/response exchange, including TLS handshake details, which usually makes it obvious whether the remaining problem is network-level or application-level.