ERR_ADDRESS_UNREACHABLE

The short version: Load the same page on mobile data. If it works, the problem is your network rather than the website, and the usual causes are a VPN or proxy capturing traffic, a router that needs restarting, or IPv6 being advertised but not actually working. If only one website fails, check what the domain resolves to with dig, since a private or stale address produces exactly this.

Key takeaways

• ERR_ADDRESS_UNREACHABLE is Chromium net error -109. It means your device could not find a route to the destination address at all, so no connection was ever attempted.
• This is a routing failure, not a server failure. A server that is down but reachable answers with a refusal or a timeout instead, which is why this error rarely means the website itself is broken.
• The fastest diagnosis is to load the same page on mobile data. If it works there, the fault is on your network, and you have narrowed it down in about ten seconds.
• IPv6 is a recurring culprit: a domain publishing an AAAA record on a network that advertises IPv6 it cannot actually deliver produces exactly this error while every other device elsewhere works fine.
• A domain resolving to an address your network cannot reach, such as a private IP from a stale or split-horizon DNS record, produces the same message for one website while everything else loads.

Error type

Browser connection error (Chromium net error -109)

Whose side

Usually your network or its routing, not the website

Fix difficulty

Easy to moderate

Common cause

No route to the destination address

What does ERR_ADDRESS_UNREACHABLE mean?

ERR_ADDRESS_UNREACHABLE is Chromium net error -109, and it describes a failure that happens earlier than most connection errors. Before a browser can request a page it needs a path to the destination address, and that path is decided by your operating system and the routers between you and the server. When no such path exists, the attempt is abandoned immediately and nothing is ever sent. Often a router along the way reports the fact explicitly with an ICMP destination-unreachable message, the mechanism RFC 792 defines for exactly this situation, and the browser turns that into the error you see.

That timing is what makes the error informative. A refused connection means your packet reached a machine which answered with a reset, so routing worked and the port was simply closed. A timeout means packets left and nothing came back, so the path may exist but something is swallowing traffic. Unreachable means the journey never started. The practical consequence is that this error rarely indicates the website is down. It points at your network, at a VPN or security tool rewriting routes, at IPv6 that is advertised but not functional, or at a domain resolving to an address your network genuinely cannot reach.

-109

The Chromium net error number behind this message, defined in net_error_list.h

ICMP

The protocol a router uses to report that a destination cannot be reached, per RFC 792

AAAA

The IPv6 DNS record type that causes this when a network advertises IPv6 it cannot deliver

How the ERR_ADDRESS_UNREACHABLE error appears

The wording changes depending on your browser, device, or server. Here is how this error commonly shows up:

example.com

This site can't be reached

example.com is unreachable.

ERR_ADDRESS_UNREACHABLE

• ERR_ADDRESS_UNREACHABLE
• net::ERR_ADDRESS_UNREACHABLE
• This site can't be reached, example.com is unreachable
• Address unreachable
• No route to host
• Destination host unreachable

Unreachable, refused, timed out and unresolved

Chromium distinguishes these because each one fails at a different stage, and confusing them sends you looking in the wrong place.

Three ways a connection fails, and what each one tells you

Chromium reports these separately because they fail at different points, and each one narrows the search to a different place.

What causes ERR_ADDRESS_UNREACHABLE?

• No working network route at all: a router that needs restarting, a dropped Wi-Fi link, or a network the device joined without receiving a usable gateway.
• A VPN, proxy, or security suite capturing traffic and failing to route it, which black-holes destinations without reporting anything useful.
• IPv6 advertised but not actually functional. The domain publishes an AAAA record, the browser prefers it, and there is no IPv6 path to the address.
• The domain resolving to an address your network cannot reach, such as a private range returned by a stale record or a split-horizon DNS setup.
• A firewall or router rule that drops traffic to a specific destination, network, or port range, so one website fails while everything else loads.
• A stale DNS cache pointing at an old address for a server that has since moved, where the old address is no longer routable.
• Corporate or captive networks that restrict outbound routing, permitting only traffic through a proxy that the browser is not configured to use.

How to find the cause fast

1. Try the same page on mobile data or another network. Working there proves the website is fine and the path from your current network is not.
2. Check whether every website fails or only this one. Everything failing points at your connection; a single website points at that domain's address.
3. Run dig +short example.com or nslookup and look at the address. A private range or an unexpected address explains it outright.
4. Disable VPNs, proxies, and traffic-inspecting security tools, then retry. These are the most common cause on an otherwise healthy connection.

Terminal

ping example.comping: sendto: No route to hostdig +short example.com10.4.2.9# a private address: your network cannot route there from here

How ERR_ADDRESS_UNREACHABLE looks from the outside

This error is generated by your own device, so nothing about it reaches the website and it will never appear in the website's logs. That cuts both ways. If you are the visitor, the website is probably fine. If you own the website, a route that stops working for one region or one network is completely invisible from your side: your server sees fewer requests and no errors at all. Checking availability from several locations outside your own network is what turns a silent regional routing failure into something you find out about, rather than something your visitors discover for you.

How to fix ERR_ADDRESS_UNREACHABLE

If you are a visitor

1. Load the same page on mobile data. If it works, the problem is your current network and the steps below are where to look.
2. Restart your router and reconnect, which clears the majority of transient routing faults.
3. Turn off any VPN, proxy, or security suite that handles traffic, then retry before turning them back on one at a time.
4. Flush your DNS cache (ipconfig /flushdns on Windows, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder on macOS) in case a stale address is being used.
5. Disable IPv6 on the network adapter temporarily. If the page then loads, your network is advertising IPv6 it cannot actually route.
6. Check what the domain resolves to with nslookup example.com. A private address such as 10.x or 192.168.x means DNS is sending you somewhere unreachable.
7. On a corporate or public network, check whether outbound traffic is restricted to a proxy the browser is not configured to use.

If you run the website

1. Confirm the domain's A and AAAA records point at addresses that are publicly routable. A stale AAAA record for IPv6 you no longer serve breaks visitors on IPv6-capable networks while everyone else is unaffected.
2. Remove AAAA records if you are not genuinely serving IPv6. Advertising an address you cannot answer on is worse than not advertising one.
3. Check that your hosting provider or firewall is not null-routing traffic from particular networks or regions, which produces this error for those visitors only.
4. Verify reachability from several external networks rather than from inside your own infrastructure, where routing usually works by definition.
5. If you moved servers, make sure old addresses stop being published and that TTLs were lowered ahead of the change so caches turn over quickly.

Still not fixed? Next steps

• Establish scope first. Does every website fail, or only this one? Everything failing points at your connection or router; a single website points at that domain's address or a route to it.
• Check what the name resolves to with nslookup or dig. An address in a private range, or one that does not match what the website publishes, explains the whole thing.
• Test the same address from a different network, mobile data being the easiest. A page that loads elsewhere confirms the website is fine and the path from where you are is not.
• Disable IPv6 on the adapter temporarily, or request the IPv4 address directly. If that fixes it, the network is advertising IPv6 connectivity it cannot deliver.
• Turn off any VPN, proxy, or security suite that captures traffic. These insert themselves into routing and can black-hole destinations without reporting anything.

Code & configuration

Copy-paste starting points. Replace example.com and the paths with your own, and test changes on staging before production.

Separate a routing failure from a DNS problem

# what does the name actually resolve to?
dig +short example.com
# 10.4.2.9        <- private: your network cannot route there

# is there a path to it at all?
ping -c 3 example.com
# ping: sendto: No route to host

Test whether IPv6 is the cause

# force IPv4 and see if the request suddenly works
curl -4 -I https://example.com
# then force IPv6
curl -6 -I https://example.com
# IPv4 working while IPv6 fails means an AAAA record you cannot reach

Flush a stale address out of the local cache

# Windows
ipconfig /flushdns
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

How to prevent ERR_ADDRESS_UNREACHABLE

A routing failure never reaches your server, so it leaves no trace in your logs: from the inside, affected visitors simply stop arriving. A stale AAAA record or a null-routed network can cut off a whole region while every internal dashboard stays green. Pulsetic checks your website from multiple locations every 30 seconds and alerts you by email, SMS, voice call, Slack, Discord, Telegram, or webhook the moment it stops answering from any of them, which is what makes a regional routing problem visible from outside instead of invisible from within.

Learn how Pulsetic's uptime monitoring detects this from the outside, across 15+ locations.

Sources and further reading

The specifications and vendor documentation this guide is written from, plus deeper reading on the parts it only summarises.

• Chromium network error list (net_error_list.h)
• MDN: An overview of HTTP
• RFC 792: ICMP, where "destination unreachable" is defined