Why does the site load on my phone's cellular data but not on Wi-Fi?

Because the two networks resolve to and route to different addresses. NET::ERR_ADDRESS_UNREACHABLE means your device found an IP for the host and then had no route to it — the network stack couldn't even reach the address to start a connection. The most common reason it splits by network is IPv6. If the host publishes an AAAA record and your Wi-Fi hands out a broken or half-configured IPv6 setup (a link-local address, no working default route, a firewall that drops outbound IPv6), the browser prefers the AAAA, tries the v6 address, and gets 'no route.' Your cellular network either has working IPv6 or is IPv4-only, so it reaches the A record instead. Same domain, same browser, different answer — because the failing piece is the route to one specific address family, not the site.

How is this different from ERR_CONNECTION_TIMED_OUT?

They fail at different layers, and the distinction tells you where to look. ERR_CONNECTION_TIMED_OUT means a route exists and your packets went out — they just never got an answer, so the browser waited and gave up (a firewall silently dropping SYNs, an overloaded origin). ERR_ADDRESS_UNREACHABLE is earlier and more absolute: the operating system looked at the destination IP and reported it had no route there at all, so there was nothing to time out. A timeout is 'I called and nobody picked up.' Unreachable is 'that number isn't connected to any exchange.' The unreachable error usually points at addressing and routing — a bad AAAA, a stale IP, a missing default route — while the timeout points at a live-but-silent host or a filtering firewall.

The domain has an AAAA record but my network is IPv4-only. Do I remove the AAAA?

Not if the server genuinely serves IPv6 — the record is correct and the fault is your local IPv6 path, which you fix on the network, not in DNS. The AAAA should only come out of DNS when it's a lie: you published a v6 address for a host that has no working IPv6 listener, or the address is wrong. That's the classic self-inflicted version of this error — an AAAA added during an IPv6 'rollout' that never finished, pointing at nothing. The rule is simple: publish an AAAA only for an address that actually answers on IPv6 from the public internet. If it doesn't, deleting the AAAA is the fix and clients quietly fall back to the A record. If it does answer for everyone except one broken network, leave DNS alone and fix that network's IPv6.

Views: 32

NET::ERR_ADDRESS_UNREACHABLE: No Route to Host

NET::ERR_ADDRESS_UNREACHABLE means there is no network route to the resolved IP, usually a broken IPv6 AAAA record. Check A vs AAAA and reachability in 3 steps. Free instant check.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Chrome (or any Chromium browser) refuses to load the page with NET::ERR_ADDRESS_UNREACHABLE. The name resolved fine — this isn’t a DNS-not-found error — but the moment the browser tried to open a connection to the address it got back, the operating system said there was no way to get there.

Chrome’s own error table is precise about it: error code -109, “The IP address is unreachable. This usually means that there is no route to the specified host or network.” That last clause is the whole diagnosis in one line. The problem isn’t the site being slow, or refusing you, or missing. The problem is that the specific IP address your machine tried to reach has no route out of your network.

Symptoms

The error text is ERR_ADDRESS_UNREACHABLE, not ERR_NAME_NOT_RESOLVED (DNS worked) and not ERR_CONNECTION_TIMED_OUT (there was never a live attempt to time out).
It very often depends on the network: broken on one Wi-Fi, fine on cellular or a different connection. That split is the biggest tell.
It can hit one site while everything else loads — the affected host resolves to an address your network can’t route to, and the rest don’t.
It shows up fast. Unlike a timeout, which makes you wait, “no route” comes back almost immediately because the stack never sends a packet it can’t deliver.
It appears or worsens right after an IPv6 change on the server side, or after moving a service to a new IP.

Why “No Route” Is Its Own Kind of Failure

Most connection errors are about what happens after your packet reaches the far side: it got refused (RESET), or nobody answered (TIMED_OUT), or the TLS negotiation broke. ERR_ADDRESS_UNREACHABLE happens before any of that. Your machine resolved the host to an IP, looked at its routing table, and found no path to that address — no default route that covers it, no interface that can carry it. It never got on the wire.

By far the most common trigger in 2026 is IPv6. Browsers prefer IPv6 when a host publishes an AAAA record, racing it against the IPv4 A record (this is Happy Eyeballs, RFC 8305). When the v6 path works, you never notice. When it doesn’t — the client has only a link-local IPv6 address, the router advertises IPv6 but has no working upstream, a firewall drops outbound v6 — the attempt to reach the AAAA address returns “unreachable.” Happy Eyeballs is supposed to fall back to IPv4 and hide this, and usually it does, but a hard “no route to host” on a misconfigured network can surface as the error instead of being papered over.

The other half of the story is on the server side: an AAAA record published for a host that doesn’t actually listen on IPv6, or an A record still pointing at a decommissioned IP that nothing routes to anymore. In both cases DNS hands out an address that leads nowhere.

Top Causes

A host with an AAAA record and a broken IPv6 path on the client network - The single most common case. The site publishes IPv6, your browser tries it first, and your network can’t route IPv6. It fails on that Wi-Fi and works everywhere with real (or absent) IPv6.
An AAAA record for a server that doesn’t serve IPv6 - Someone added a v6 address during a rollout that never finished, or copied a template. The address is in DNS but nothing listens there, so every client that prefers it hits a dead route. This one is the site owner’s to fix, and it breaks for lots of visitors, not just one network.
A stale A record pointing at a decommissioned IP - The server moved, the old address was reclaimed, and now the name resolves to an IP that no longer routes anywhere. Same symptom, IPv4 flavor.
A private or unroutable address returned to the wrong client - Split-horizon DNS leaking an RFC 1918 address (like 10.x or 192.168.x) to a client that isn’t on that internal network. The client has no route to a private range it isn’t part of.
A local routing or VPN problem - No default route on the machine, a VPN in split-tunnel mode that swallowed the route to that destination, or a router that lost its upstream. Here the fault is entirely local and the DNS is innocent.

Diagnose with DechoNet

DNS Check shows exactly which addresses the name hands out — both the A (IPv4) and AAAA (IPv6) records. That’s the fork in the road: if there’s an AAAA and you’re on a network with broken or missing IPv6, you’ve found it. If the only address is an A record pointing somewhere that no longer answers, that’s the stale-IP case. Seeing what the name actually resolves to, from outside your own network, separates “the record is wrong” from “my network can’t route to a correct record.”
Port Check tests whether the resolved address actually accepts connections on the port you need (usually 443). From an external vantage point, it tells you whether the server is reachable at all on that address — which cleanly separates “the whole world can’t reach this IP” from “only my network can’t.”

Resolution Checklist

Run a DNS check and read both records. Note whether the host has an AAAA (IPv6) address in addition to the A (IPv4) one. If it does, IPv6 is your first suspect.
Test from a second network. Load the site on cellular or a different connection. If it works there and fails on the first one, the fault is that network’s route — most often its IPv6 — not the site.
If you control the domain and the AAAA points at a server that doesn’t actually serve IPv6, remove the AAAA. Clients fall back to the A record and the error clears for everyone.
If the A record points at an IP that no longer answers anywhere (confirm with a port check), fix the record to the current address.
If it’s local, check your own routing: disable a suspect VPN, confirm you have a working default route, and — only as a diagnostic, not a permanent fix — try temporarily disabling IPv6 on the adapter to confirm the v6 path is the culprit.
Re-test after each change. “No route” clears the instant a routable address is in play.

When to Escalate

If the site is unreachable for many users and it has an AAAA record, treat it as a server-side IPv6 problem: the record advertises an address that doesn’t answer, and that’s a DNS/hosting fix, not something visitors can work around.
If your whole network hits ERR_ADDRESS_UNREACHABLE for external IPv6 destinations, that’s a router or ISP IPv6 issue — escalate to whoever runs the network. Disabling IPv6 on one laptop is a bandage; the network’s broken v6 path is the wound.