Troubleshooting Network Connectivity Problems in Linux: A Step-by-Step Guide

Network problems on Linux rarely announce themselves clearly. One moment everything works, the next you're staring at a timeout. The good news is that Linux gives you precise tools to trace the fault from the physical layer all the way up to DNS — if you know where to look and in what order.

This guide follows a layered diagnostic flow: physical link → IP assignment → routing → DNS → firewall → services. Work through it top to bottom and you'll isolate the problem before reaching for a reboot.

Start with the Basics — Is the Interface Up?

Before anything else, confirm that Linux actually sees your network interface and that it has an active link. Run ip link show to list all interfaces and their states.

Look for your interface name — it might be eth0, enp3s0, or wlan0 depending on your system. The output will show something like state UP or state DOWN. If the interface is DOWN, bring it up manually:

sudo ip link set enp3s0 up

If the interface doesn't appear at all, the driver may not be loaded. Check lspci or lsusb (for USB adapters) to see if the hardware is detected. A missing interface almost always points to a driver issue, not a configuration problem.

For wireless interfaces, also verify that the radio isn't blocked. rfkill list will show whether Wi-Fi is soft-blocked or hard-blocked. A soft block can be cleared with rfkill unblock wifi; a hard block means a physical switch or BIOS setting needs attention.

Check Your IP Address and Default Route

A working interface still needs a valid IP address and a default gateway to reach anything outside your local network. Use ip addr show to check the assigned address.

If the interface shows no IP (or only a link-local 169.254.x.x address), DHCP either failed or was never attempted. On NetworkManager-managed systems, run nmcli device status to see the connection state. On systems using systemd-networkd, check networkctl status.

To verify the default route exists, run:

ip route show

You should see a line starting with default via followed by your gateway IP. If that line is missing, you have no path out of your local network. For DHCP setups, restarting the network service usually fixes this (covered in the last section). For static configurations, check your interface config file — on Debian-based systems that's typically in /etc/network/interfaces, on Red Hat-based systems in /etc/sysconfig/network-scripts/.

Test Connectivity Layer by Layer

Use ping in a deliberate sequence to pinpoint exactly where the connection breaks. Each step rules out a different layer of the network stack.

• Ping your gateway (e.g., ping 192.168.1.1) — if this fails, the problem is local: bad IP config, wrong subnet, or a link issue.
• Ping a public IP (e.g., ping 8.8.8.8) — if the gateway responds but this fails, routing or your ISP is the issue.
• Ping a hostname (e.g., ping google.com) — if the public IP works but the hostname doesn't, you have a DNS problem, not a connectivity problem.

If you need to trace the path packets take, traceroute (or tracepath, which doesn't require root) shows each hop. A route that dies at your gateway points to a local config issue; one that dies several hops out suggests an upstream problem you can't fix yourself.

Diagnose DNS Resolution Failures

DNS failure is the most common reason ping works with an IP but fails with a domain name. Start by checking what DNS servers Linux is actually using.

On systems without systemd-resolved, the answer is in /etc/resolv.conf — look for nameserver lines. On systems running systemd-resolved (common on Ubuntu 18.04+ and many modern distros), /etc/resolv.conf may just point to 127.0.0.53, and the real configuration lives in the resolved service itself. Check it with:

resolvectl status

To test resolution directly, use dig or nslookup:

dig google.com
nslookup google.com 8.8.8.8

If dig google.com fails but dig google.com @8.8.8.8 succeeds, your configured nameserver is the problem — not DNS in general. Replace the nameserver entry in /etc/resolv.conf or reconfigure your network connection to use a working DNS server.

Also check /etc/nsswitch.conf — the hosts: line controls resolution order. It should include dns (e.g., hosts: files dns). If dns is missing, the system won't query nameservers at all. The /etc/hosts file is checked first by default, so a stale entry there can silently override DNS for specific hostnames.

Inspect Firewall Rules

A firewall that's blocking outbound traffic or ICMP will make your connection look broken even when the network itself is fine. Check which firewall tool your system uses before drawing conclusions.

On systems using ufw (common on Ubuntu), run sudo ufw status verbose. If ufw is active and you want to test without it temporarily, sudo ufw disable will do it — just remember to re-enable it after testing.

For iptables, list all rules with:

sudo iptables -L -n -v

Look for DROP or REJECT rules in the OUTPUT or FORWARD chains. On systems using nftables (the default on Debian 10+ and Fedora), use sudo nft list ruleset instead.

A quick way to test whether the firewall is the culprit: flush all rules temporarily with sudo iptables -F and retry your connection. If it works, a specific rule was blocking traffic. Restore your rules from backup or reconfigure carefully — don't leave the firewall flushed on a production system.

Read the Logs — dmesg and journalctl

When surface-level commands don't reveal the problem, kernel and service logs usually do. dmesg shows kernel ring buffer messages, including driver errors and link state changes.

dmesg | grep -i -E 'eth|enp|wlan|network|link'

Look for messages like Link is Down, firmware load failures, or driver errors. These point to hardware or driver problems that no amount of configuration will fix without addressing the underlying cause.

For service-level issues, journalctl is more useful:

journalctl -u NetworkManager --since "10 minutes ago"
journalctl -u systemd-networkd -n 50

Failed DHCP negotiations, authentication errors on WPA-secured networks, and interface bring-up failures all show up here with timestamps. If you see repeated DHCP timeouts, the issue is likely upstream (router not responding) rather than a Linux misconfiguration.

Restart and Reconfigure Network Services

Once you've identified the problem layer, restarting the relevant service is often the fastest fix. On NetworkManager-managed systems:

sudo systemctl restart NetworkManager

On systems using systemd-networkd:

sudo systemctl restart systemd-networkd
sudo systemctl restart systemd-resolved

To renew a DHCP lease without restarting the whole service, use nmcli:

nmcli device reapply enp3s0

Or with dhclient directly: sudo dhclient -r enp3s0 && sudo dhclient enp3s0.

A full reboot is rarely necessary for network issues and should be a last resort, not a first response. The exception is driver-level problems — if dmesg shows firmware errors or the interface disappears entirely, a reboot (or at minimum a module reload with modprobe) may be required.

One thing worth noting: on systems where both NetworkManager and systemd-networkd are running simultaneously, they can conflict. Check which one owns your interface with nmcli device status — interfaces marked as unmanaged are handled by systemd-networkd or configured manually.

Frequently Asked Questions

Why does my network interface show "UP" but I still have no internet access?

"UP" only means the interface is active at the link layer — it says nothing about IP assignment, routing, or DNS. Check for a valid IP with ip addr, a default route with ip route, and DNS resolution with dig. Any of these missing will break internet access even with a healthy interface.

How do I find out which DNS server Linux is using?

Run cat /etc/resolv.conf for the configured nameservers. On systems with systemd-resolved, run resolvectl status for the full picture, including per-interface DNS settings that resolv.conf won't show.

What is the difference between NetworkManager and systemd-networkd?

NetworkManager is designed for dynamic environments — laptops, desktops, systems that switch between Wi-Fi and Ethernet. It handles connection profiles and has both CLI (nmcli) and TUI (nmtui) interfaces. systemd-networkd is better suited for servers and containers where network config is static and predictable. Most desktop distros default to NetworkManager; many server and minimal installs use systemd-networkd.

How do I renew my DHCP lease on Linux?

With NetworkManager: nmcli device reapply <interface>. With dhclient directly: sudo dhclient -r <interface> && sudo dhclient <interface>. With systemd-networkd: restart the service with sudo systemctl restart systemd-networkd.

Why does ping work with an IP address but not a domain name?

This is a DNS failure, not a connectivity failure. Your routing works fine, but the system can't resolve hostnames to IP addresses. Check /etc/resolv.conf for valid nameserver entries, test with dig google.com, and verify that /etc/nsswitch.conf includes dns in the hosts: line.