Fix "connect: Network is unreachable" on Linux

ip -br addr
ip route
# desktop / NetworkManager systems
nmcli device status
sudo nmcli networking off && sudo nmcli networking on

Common variants of the message:

ping: connect: Network is unreachable
ssh: connect to host 203.0.113.10 port 22: Network is unreachable
curl: (7) Failed to connect to 2606:4700::6810:84e5 port 443: Network is unreachable
Cannot initiate the connection to archive.ubuntu.com:80 (2620:2d:4000:1::17). - connect (101: Network is unreachable)

What the error means

The kernel returned ENETUNREACH: it looked in your routing table and found no route that matches the destination address, so it refused to send anything. The error appears instantly, with no waiting, because the packet never leaves your machine. That makes it different from No route to host (a route exists but the host did not answer) and from timeouts (packets left but nothing replied).

Check what the kernel knows:

ip route
ip -6 route

Example output of a working IPv4 setup:

default via 192.168.1.1 dev wlan0 proto dhcp src 192.168.1.10 metric 600
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.10 metric 600

If the default line is missing, every address outside your local subnet is unreachable. If ip route prints nothing, the interface has no address at all.

Cause 1: not connected, or the interface is down

Wi-Fi dropped, the cable is out, the VM's virtual NIC is disconnected, or NetworkManager has not brought the connection up after boot. Check link state and addresses:

ip -br link
ip -br addr
nmcli device status

Example output:

lo        UNKNOWN  127.0.0.1/8 ::1/128
enp3s0    DOWN
wlan0     UP       fe80::1c2b:3aff:fe4d:5e6f/64

Only a fe80:: link-local address means the link is up but DHCP gave no address. Reconnect:

nmcli connection show
sudo nmcli connection up "Home WiFi"
# a minimal server without NetworkManager
sudo ip link set enp3s0 up

For wireless problems such as missing drivers or a network that will not connect, follow fix Wi-Fi on Linux.

Cause 2: no default gateway (static IP or DHCP problem)

The interface has an address but there is no default route. This happens with a static configuration that forgot the gateway, or a DHCP server that did not send one. As a temporary test, add the route by hand (it disappears on reboot):

sudo ip route add default via 192.168.1.1 dev enp3s0
ping -c 3 1.1.1.1

If that works, make it permanent in your network configuration:

# NetworkManager (desktops, Fedora, many servers)
sudo nmcli connection modify "Wired connection 1" ipv4.gateway 192.168.1.1
sudo nmcli connection up "Wired connection 1"

# Ubuntu Server netplan: /etc/netplan/50-cloud-init.yaml or similar
#   routes:
#     - to: default
#       via: 192.168.1.1
sudo netplan try

On Debian servers using /etc/network/interfaces, add gateway 192.168.1.1 under the interface stanza and run sudo systemctl restart networking from a console, not over SSH. Netplan's old gateway4: key is deprecated; use the routes: form shown above. Our guide to setting a static IP walks through each method.

Cause 3: IPv6 address but no IPv6 connectivity

If only IPv6 addresses fail (the address in the message contains colons), your network has no IPv6 default route. Many sites publish both IPv4 and IPv6 addresses; well-behaved programs try the other address, but some tools stop at the first error or print it before falling back. Confirm:

ip -6 route | grep default || echo "no IPv6 default route"
ping -4 -c 2 deb.debian.org
ping -6 -c 2 deb.debian.org

Workarounds while you fix IPv6 on the router or with your ISP:

# one-off
curl -4 https://example.com
ssh -4 [email protected]
# apt: always use IPv4
echo 'Acquire::ForceIPv4 "true";' | sudo tee /etc/apt/apt.conf.d/99force-ipv4

Prefer fixing the network over disabling IPv6 system-wide. Disabling it with sysctl can break software that expects at least ::1 to exist.

Cause 4: a VPN or a manual route removed the default

VPN clients replace or override the default route while connected. If the VPN crashes, or you disconnect it uncleanly, the default route may be gone. Check for stale tunnel routes and restore the connection:

ip route | grep -E 'tun|wg|ppp'
sudo nmcli connection down "My VPN"
sudo nmcli connection up "Wired connection 1"

Policy routing setups (WireGuard with wg-quick, for example) can use extra routing tables; ip rule and ip route show table all show the full picture.

Cause 5: containers and network namespaces

A container started with --network none, a systemd service with PrivateNetwork=yes, or a sandboxed app without network permission sees only a loopback interface, so everything is unreachable. Check the service or container options rather than the host network. Inside WSL, network problems usually come from the Windows side; wsl --shutdown from Windows and restarting the distribution regenerates its network.

Distro notes

• Ubuntu Desktop, Mint, Fedora, openSUSE desktops: NetworkManager manages everything; use nmcli or the settings app. The nmcli cheat sheet lists the commands.
• Ubuntu Server: netplan writes configuration for systemd-networkd. Use sudo netplan try, which rolls back automatically if you lose access.
• Debian server installs: often ifupdown with /etc/network/interfaces.
• Arch: whatever you installed: NetworkManager, systemd-networkd (networkctl status) or iwd. A fresh install without any network manager enabled has no network after reboot.

How to prevent it

• When writing static configuration, always set address, prefix, gateway and DNS together, and test with a rollback (netplan try) or from a console.
• Make sure exactly one network manager is enabled; two competing ones can remove each other's routes.
• If your network has no IPv6, configure clients accordingly rather than leaving half-working IPv6 addresses around.

Once routing works, a remaining "could not resolve" error is a DNS issue: see Temporary failure in name resolution. For general background, read the Linux networking basics guide.

Frequently asked questions