How to Fix connect: Network is unreachable in Linux and BIND

Updated: 4 November 2026 · Applies to: Debian 13 (iproute2 6.15, BIND 9.20.29), AlmaLinux 10.2 (BIND 9.18.33), Ubuntu 24.04 (BIND 9.18.39) and Ubuntu 26.04 (BIND 9.20.24)

connect: Network is unreachable means your server's routing table has no route to the address you are connecting to, so the connection fails before a single packet leaves the server. There are three usual causes: no default gateway, a network interface that is down, or an IPv6 address on a server without IPv6 routing. Run ip route get with the address you tried: if it also says "Network is unreachable", add the missing route. In BIND (named), the same problem shows up as "network unreachable resolving" log lines, and named -4 stops them.

Where you see the error

The same missing route gives these messages (tested on Debian 13 and AlmaLinux 10.2):

$ ping -c1 203.0.113.10
ping: connect: Network is unreachable
$ ssh root@203.0.113.10
ssh: connect to host 203.0.113.10 port 22: Network is unreachable
$ wget -nv http://[2001:db8::1]/
failed: Network is unreachable.
$ curl http://203.0.113.10/
curl: (7) Failed to connect to 203.0.113.10 port 80 after 0 ms: Could not connect to server
$ ip route get 203.0.113.10
RTNETLINK answers: Network is unreachable

Two similar errors mean something else:

• From 192.0.2.10 icmp_seq=3 Destination Host Unreachable: a route exists, but no device on your local network answers for that address (a wrong gateway IP, or the host is off).
• ping waits and ends with 100% packet loss: packets left your server but nothing answered. Check firewalls and the remote host, not your routes.

Step 1: find out which case you have

1. Ask the kernel how it would reach the address. A working route shows the gateway:

   $ ip route get 203.0.113.10
   203.0.113.10 via 192.0.2.1 dev eth0 src 192.0.2.10 uid 0

2. Check that the interface is UP and has an address:

   $ ip -br addr
   lo               UNKNOWN        127.0.0.1/8 ::1/128
   eth0             UP             192.0.2.10/24 fe80::7082:5fff:feaf:76da/64

3. Look for a default line in the routing table. In our test, after the default route was deleted only the local subnet was left:

   $ ip route
   192.0.2.0/24 dev eth0 proto kernel scope link src 192.0.2.10

4. If only IPv6 addresses fail, run ip -6 route. No default line there means the server has no IPv6 route (see the IPv6 section below).

Step 2: add the missing default gateway

Use the gateway address your provider gave you with the IP address, then add it for a quick test:

sudo ip route add default via 192.0.2.1

The gateway must be inside your server's own subnet. If it is not, ip refuses it:

$ ip route add default via 198.51.100.1
Error: Nexthop has invalid gateway.

If the interface was down, sudo ip link set eth0 up brings it back, but in our test the default route did not come back with it: only the subnet route returned and the default route had to be added again.

A route added with ip is lost on reboot. Make it permanent in the network configuration your system uses:

• AlmaLinux, Rocky Linux, RHEL (NetworkManager): find the connection name with nmcli con show, then:

  sudo nmcli con mod "eth0" ipv4.gateway 192.0.2.1
  sudo nmcli con up "eth0"

  According to NetworkManager, the gateway only applies when the connection also has addresses set, and it creates the default route.
• Ubuntu (netplan): under your interface in /etc/netplan/*.yaml:

        routes:
          - to: default
            via: 192.0.2.1

  gateway4 is deprecated according to netplan. Apply with sudo netplan try: it rolls the change back after 120 seconds unless you confirm, which protects you over SSH.
• Debian (ifupdown): add gateway 192.0.2.1 to the iface eth0 inet static block in /etc/network/interfaces.

The full static IP setup is in How to Set Static IP Address and Configure Network in Linux? If a network change cuts off SSH on a Ucartz VPS, log in through the VNC console (How to Access Your VPS via VNC in Virtualizor) and fix it there.

IPv6: Network is unreachable only for IPv6 addresses

A server without IPv6 routing gives this error for every IPv6 address, for example ping -6 2001:db8::1 or an SSH connection to an IPv6 address. Programs that try several addresses usually recover on their own. In our test the server had an IPv6 address but no IPv6 gateway; curl tried the IPv6 addresses first and then connected over IPv4:

$ curl -sv -o /dev/null http://deb.debian.org/debian/
*   Trying [2001:db8:600::644]:80...
* Immediate connect fail for 2001:db8:600::644: Network is unreachable
...
*   Trying 198.51.100.132:80...
* Connected to deb.debian.org (198.51.100.132) port 80

(Shortened, with the addresses replaced by documentation examples.) apt-get update worked on the same server without any warning. Your options:

• Use IPv4 for that command: ping -4, ssh -4, curl -4, or apt-get -o Acquire::ForceIPv4=true update.
• If your server has IPv6, add its IPv6 gateway the same way as above (ipv6.gateway in NetworkManager, an IPv6 via in netplan).
• If you do not use IPv6, remove the half-configured address or turn IPv6 off: How to Disable IPv6 on Ubuntu Linux? or How to Disable IPv6 on a Specific Network Interface Only.

BIND (named): network unreachable resolving

A DNS server on a host without IPv6 routing fills its log (journalctl -u named) with lines like these, which we got from BIND 9.20 in a lab container with IPv4 routing and no IPv6 route:

network unreachable resolving './DNSKEY/IN': 2001:500:2f::f#53
network unreachable resolving './NS/IN': 2001:7fd::1#53

named tries the IPv6 addresses of the root and other name servers. Commenting out listen-on-v6 does not help: that option only controls where named listens. Our test had listen-on-v6 { none; }; and still logged 37 of these lines within seconds. The fix is the -4 option, which according to the named manual makes named "use only IPv4, even if the host machine is capable of IPv6":

1. AlmaLinux, Rocky Linux and RHEL: edit /etc/sysconfig/named and add

   OPTIONS="-4"

   The service runs /usr/sbin/named -u named -c ${NAMEDCONF} $OPTIONS, so the option is picked up from there.
2. Debian and Ubuntu: edit /etc/default/named and add -4 to the existing line. Keep -u bind: according to the named manual, it makes named switch to that user after opening its ports.

   OPTIONS="-u bind -4"

3. Restart and check:

   sudo systemctl restart named
   sudo journalctl -u named --since "5 min ago" | grep -c unreachable

With -4, our test logged none of these lines. If you prefer to keep this in the configuration file, the top-level statement server ::/0 { bogus yes; }; in named.conf (outside the options block) stopped the IPv6 queries just as well. Remove either setting once the server has working IPv6. More on the file itself: DNS configuration file /etc/named.conf explained.

Official documentation: BIND 9 Administrator Reference Manual, netplan YAML reference.