ERR_ADDRESS_UNREACHABLE: No Route to the Server. How to Fix

net::ERR_ADDRESS_UNREACHABLE is Chromium error -109: «The IP address is unreachable. This usually means that there is no route to the specified host or network» (net_error_list.h). DNS already worked and returned an IP address; the failure happens when Chrome tries to open the TCP connection to it. The operating system reports that the host or network cannot be reached (EHOSTUNREACH or ENETUNREACH on Linux and macOS, WSAEHOSTUNREACH or WSAENETUNREACH on Windows), and Chrome maps that to -109.

That answer comes either from your own machine (it has no route to that network) or from a router or firewall that sends back an ICMP unreachable message. It is not a DNS failure (that is ERR_NAME_NOT_RESOLVED), not a refused connection (the host is up but nothing listens), not a timeout (packets vanish with no answer), and not a TLS or certificate error: no TLS handshake ever started.

Most reports involve private addresses: a device that is switched off or on another subnet or VLAN, a VPN that captures the route to 10.x or 192.168.x, or being on the guest Wi-Fi when the target is on the main network. On macOS 15 (Sequoia) and later, apps need the Local Network permission; if Chrome does not have it, local addresses fail with this error while public sites work.

For public websites the usual causes are DNS returning an address that cannot be reached from where you are (a stale record, a private IP leaking from split-horizon DNS, or an IPv6-only site on a network without IPv6) and firewalls configured to reject with an ICMP host-unreachable or host-prohibited message instead of dropping. Such a reject produces «No route to host» on the client even though the route is fine.

A CDN or reverse proxy rarely causes this error directly, because the browser only connects to the proxy's public addresses and those are routable. The one check that still applies: make sure your DNS points at the proxy and not at an origin address that is private or firewalled. If an A or AAAA record for a proxied host was switched to DNS-only, or a new subdomain was created with the origin's internal IP, visitors connect straight to an address they cannot reach.

dig +short example.com A
dig +short example.com AAAA
# Private ranges such as 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16
# in public DNS mean visitors are sent somewhere they cannot reach

1. Check what DNS returns from more than one resolver: dig +short example.com @1.1.1.1 and dig +short example.com @8.8.8.8. Remove stale or private addresses. For resolver-side issues see DNS resolution fixes.
2. Check IPv6. If you publish an AAAA record, the server must actually answer on it: curl -6 -v https://example.com/. A broken AAAA record hurts IPv6-capable visitors only.
3. Find where the path stops:

   traceroute -n 203.0.113.10
   mtr -rwc 20 203.0.113.10

   A trace that ends at your provider's edge with !H or !N (host or network unreachable) points at routing or a reject rule there.
4. Check firewall reject types on the server and the provider firewall: iptables -S | grep -E 'host-unreach|host-prohib|net-unreach'. Rules that should block nobody but answer with these types turn into this error for clients.
5. Confirm the server is up and has the address: ip addr and ip route on the host, and the provider's panel for a down instance or a detached IP.

More scenarios: ERR_ADDRESS_UNREACHABLE fix guide.

1. Check the address. If it is a local one (192.168.x.x, 10.x.x.x, .local), make sure the device is on and you are on the same network, not the guest Wi-Fi or mobile data.
2. On a Mac: System Settings > Privacy & Security > Local Network, and allow Google Chrome; restart Chrome after changing it.
3. Disconnect a VPN, or connect it if the target is on your company network. VPNs commonly take over routes to private ranges.
4. For a public site, try another network. If it works there, your network or provider cannot route to that address; secure DNS (Chrome Settings > Privacy and security > Security > Use secure DNS) helps if your resolver returns a wrong address.

Clearing the browser cache does not help: no connection was made. If the site is unreachable from every network, it is down or misconfigured on the owner's side.

ping -c 3 203.0.113.10
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/
# 200

Some hosts block ICMP, so a failed ping alone proves nothing; the TCP test with curl is the one that matters. To test reachability of the host and port from outside your own network, use the ping and port checker.

• ERR_CONNECTION_RESET — the connection was established, then reset
• ERR_NAME_NOT_RESOLVED — DNS returned no address at all
• ERR_CONNECTION_TIMED_OUT — packets vanish with no answer
• ERR_CONNECTION_REFUSED — host reachable, nothing listening