Troubleshooting

ERR_ADDRESS_UNREACHABLE: Causes and the Fix

· 5 min read · 5 views · Getwebup

The short answer

ERR_ADDRESS_UNREACHABLE means your network could not get a packet to the IP address at all - there is no route to it. DNS worked; the address it returned is either dead, private, or blocked on the network you are using. Run dig +short yourdomain.com to see which IP you are being sent to, then ping that IP directly. If DNS returns nothing, it is a DNS problem instead.

Not sure which error you have? Decode Chrome's code first — "This Site Can't Be Reached" in Chrome: Every Code Decoded

ERR_ADDRESS_UNREACHABLE is one of the more honest errors Chrome prints. It is not saying the site is down, or that it timed out waiting - it is saying the network refused to even try, because it has no route to the address it was given. That narrows the problem considerably.

What "unreachable" actually means here

DNS already worked. The browser asked for an IP, got one, and handed it to the operating system, and the operating system replied that it does not know how to reach that address at all - or the network in between sent back an ICMP "destination unreachable". No connection was ever attempted.

That rules out a whole class of causes. The web server being stopped would give you ERR_CONNECTION_REFUSED. A firewall dropping packets silently would give you ERR_CONNECTION_TIMED_OUT. Getting "unreachable" means the failure happened at the routing layer, before either of those could matter.

Step 1: find out which IP you are being sent to

Almost every real instance of this error comes down to the answer to one question - what address is the domain actually resolving to right now?

dig +short yourdomain.com

On Windows without dig, nslookup yourdomain.com does the same job. Look hard at what comes back:

  • A private address - anything starting 10., 172.16-31., 192.168., or 169.254. This is the single most common cause. A record meant for a local network has ended up in public DNS. It will work on the LAN where that address exists and fail everywhere else.
  • An address you do not recognise - the record points at a server that has been decommissioned, or at an old host you migrated away from.
  • Nothing at all - this is not really an address problem. An empty answer means DNS failed, and you want ERR_NAME_NOT_RESOLVED or DNS_PROBE_FINISHED_NXDOMAIN instead.
  • The correct public IP - then the record is fine and the problem is between you and it. Continue below.

Step 2: test that address directly

Take the IP out of the equation as a name and test it as a number:

ping -c 4 203.0.113.10
curl -sS -o /dev/null -w '%{http_code}\n' --resolve yourdomain.com:443:203.0.113.10 https://yourdomain.com

The --resolve flag tells curl to skip DNS and use the address you name, which is how you prove whether the record or the route is at fault. If the ping fails and the curl fails, the address is unreachable from your network. If both succeed, the address is fine and Chrome is working from a cached, older record.

The three causes worth checking, in order

1. A stale or wrong DNS record

After a migration, the A record may still point at the old server's IP - and if that server has been released back to the provider, the address may no longer route anywhere. Set the record to the current IP, and check that you have changed it at the nameservers the domain is actually using, which is not always the ones you remember:

dig NS yourdomain.com +short
dig @ns1.yourprovider.com yourdomain.com A +short

Editing a zone at a provider the domain no longer delegates to is a common and very frustrating way to change nothing at all.

2. A VPN, proxy or corporate network in the way

A VPN rewrites your routing table. If the tunnel is up but the route for that destination is broken, or split tunnelling is sending some traffic into a tunnel that no longer carries it, the result is exactly this error. Disconnect, reload once, reconnect. Corporate and campus networks do the same thing with policy routing and DNS filtering.

3. The mobile-network case

Indian mobile carriers commonly block traffic to private ranges and to some hosting ranges outright. If a site loads on office Wi-Fi and fails on 4G with this error, and the domain resolves to a private address, you have found it - the record needs to be a public IP.

The local fixes, when the address checks out

If the record is correct and the IP responds from elsewhere, the problem is cached or local state:

  1. Clear Chrome's host cache at chrome://net-internals/#dns, then flush socket pools at chrome://net-internals/#sockets. Chrome caches independently of the OS.
  2. Flush the OS resolver - ipconfig /flushdns on Windows, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder on macOS, resolvectl flush-caches on Linux.
  3. Switch the adapter to 1.1.1.1 or 8.8.8.8 and retest, which rules out an ISP resolver handing back an old address.
  4. Restart the router. This is the one case where the folk remedy is genuinely relevant: consumer routers cache DNS and hold routing state, and both can be stale.

On a server you administer

If you are hosting the site and users report this error, check that the machine's public address is what DNS says it is. On a VPS:

curl -sS https://api.ipify.org; echo
ip -4 addr show scope global

A mismatch between that and your A record is the whole problem. It happens after a rebuild, after a failover, and after moving between providers - the server is healthy and simply is not the machine the domain points at any more.

Questions people actually ask

err_address_unreachable chrome networking dns troubleshooting