ERR_ADDRESS_UNREACHABLE

Error ERR_ADDRESS_UNREACHABLE appears in Chrome, Edge and other Chromium browsers when the browser obtained an address and tried to open a connection to it, but the network could not deliver traffic to that host. Unlike a name-resolution failure, the domain resolved fine — a DNS lookup returned an IP address — yet no working route existed to reach it. The operating system reports the same condition as “No route to host” (the POSIX error EHOSTUNREACH), and the browser surfaces it under this name.

What it means

Once DNS returns an address, the browser hands that IP to the operating system and asks it to open a connection. The OS consults its routing table to find a path to the address. If a router along the way answers that the destination is unreachable — an ICMP “destination unreachable” message — or if the packet is simply dropped with no route at all, the connection cannot be established and the browser reports this error rather than waiting for a server that will never answer.

This matters because it is not the same as a slow server. A timeout (ERR_CONNECTION_TIMED_OUT) means packets were sent and nothing came back, so the real cause stays unknown. ERR_ADDRESS_UNREACHABLE is a definite answer: the network actively told the machine that no path exists to that address. That normally points at routing, subnetting, a firewall rule, or a genuinely offline host rather than at an overloaded web server.

Because the failure happens below the web layer, the same message can appear for a web server, an SSH host, a game server or a printer. It often shows up right after a network change: a new router, a VPN that just connected, a laptop that moved between Wi-Fi networks, or a service whose address changed. Reading the error together with what changed just before it appeared usually identifies the layer that broke.

Common causes

• The target host is offline, or its IP address changed since the link or bookmark was saved.
• The device has no usable default gateway or has the wrong subnet mask, so it has no route off the local network.
• DHCP failed and the adapter fell back to a self-assigned 169.254.x.x (APIPA) address with no gateway.
• A VPN, proxy, or firewall is blocking or rerouting traffic to that destination.
• A remote firewall is refusing your source address and answering “unreachable” instead of dropping the packet.

How to fix it

1. Confirm the host is actually up. Try reaching it from another device or network. If nothing can reach it, the problem is the target service, not your browser.
2. Check the local route. On Windows run ipconfig /all and confirm a Default Gateway and Subnet Mask are present and sensible. On Linux or macOS use ip route or netstat -rn to look for a default route.

   ipconfig /all
   route print

3. Clear a failed DHCP lease. If the adapter shows a 169.254.x.x address, ask the router for a new one:

   ipconfig /release
   ipconfig /renew
   ipconfig /flushdns

4. Reset the network stack (Windows, elevated prompt). This clears a corrupted route or socket state, then restart:

   netsh winsock reset
   netsh int ip reset

5. Bypass VPN, proxy and firewall for a test. Disconnect the VPN and disable any proxy, then retry. If it works, adjust those rules to allow the destination address or the required port instead of blocking it.

How to prevent it

Treat network changes carefully. Leave adapters on DHCP unless you genuinely need a fixed address, and if you do set a static one, fill in the gateway and subnet mask correctly — a wrong subnet mask is a classic way to lose the route and produce this error. Keep router firmware current, and restart the router if the whole network suddenly becomes unreachable.

Know what your VPN captures. A split-tunnel profile that sends local addresses through the tunnel can make internal hosts look unreachable, while a full-tunnel profile can hide the local network entirely. Keep VPN and firewall software updated, and re-check the rules after any upgrade, because defaults sometimes change.

Finally, watch the services you depend on. A simple uptime check or HTTP probe tells you when a host goes offline from an alert, rather than leaving you to discover it through a browser error. When an address is wrong, fix the link at its source so the same dead URL does not return next week.