ERR_ADDRESS_UNREACHABLE is a Chrome error meaning the browser already resolved the site's IP address, but the operating system found no network route to it. DNS succeeded — the IP itself is unreachable. Usual culprits: a stalled router, a VPN that hijacked routing, an AAAA record without real IPv6 connectivity, or a private IP in DNS.
This guide explains what net::ERR_ADDRESS_UNREACHABLE means, how it differs from ERR_NAME_NOT_RESOLVED and ERR_CONNECTION_TIMED_OUT, which causes belong to the visitor, the network, or the site owner, and how to diagnose and fix the problem with ping, tracert, curl, and dig.
What does ERR_ADDRESS_UNREACHABLE mean?
In Chromium's network error list, ERR_ADDRESS_UNREACHABLE is error -109: "The IP address is unreachable." The key detail: DNS has already completed successfully. The browser knows which IP to contact, issues a connect() call — and the OS answers with EHOSTUNREACH or ENETUNREACH: no route to that host. No interface or gateway knows a path to the address.
That places the error between two neighbours. With ERR_NAME_NOT_RESOLVED the failure happens one step earlier: DNS never returned an IP. With ERR_CONNECTION_TIMED_OUT it happens one step later: a route exists, packets leave, but no reply arrives in time. ERR_ADDRESS_UNREACHABLE sits in the middle: the name resolved, but no road leads to the address.
Rule of thumb: NAME_NOT_RESOLVED — "I don't know where to go," ADDRESS_UNREACHABLE — "I know where, but there is no road," CONNECTION_TIMED_OUT — "the road exists, but nobody answers."
Why does ERR_ADDRESS_UNREACHABLE happen? Common causes
Router or local network problems
The most common household cause. The router has frozen, lost its WAN link, or hands clients a broken default gateway via DHCP — devices get an IP, yet packets never leave the LAN. A static IP with the wrong gateway or subnet mask produces the same picture: no route to the outside world.
A VPN or proxy hijacked the routing table
VPN clients insert their own routing-table entries and funnel traffic through a tunnel. If the tunnel drops but the routes stay, or split tunneling is misconfigured, some destinations point "into nowhere": the OS sends packets through an interface that no longer exists. Corporate proxies and antivirus "traffic protection" hook into the stack the same way and can leave broken routes after a crash.
IPv6 brokenness: an AAAA record exists, but IPv6 connectivity does not
A classic scenario for site owners. The DNS zone publishes an AAAA record and the browser tries IPv6 first — but either the visitor's ISP has no IPv6 routing, or the server has an IPv6 address assigned while the web service never listens on it. Happy Eyeballs (RFC 8305) usually falls back to IPv4, but not always, so some visitors hit ERR_ADDRESS_UNREACHABLE while others browse normally.
A private IP address published in DNS
If the A record points at a private address (192.168.x.x, 10.x.x.x, 172.16–31.x.x), the site opens only inside the network where that address exists. For everyone else there is no route to private ranges — the error is guaranteed. Typical origins: configuration copied from staging or the server's internal IP pasted into the public DNS panel.
Firewalls and mobile carrier filtering
An aggressive firewall can drop packets to specific subnets, and some mobile carriers and public Wi-Fi networks filter address ranges or block IPv6 entirely. The symptom is recognisable: the site fails on mobile data but works on home Wi-Fi, or vice versa.
Causes, diagnostics, and fixes: summary table
| Cause | Side | How to diagnose | How to fix |
|---|---|---|---|
| Router frozen or WAN link down | Client / network | No site opens; ping 8.8.8.8 fails | Reboot the router, check the WAN link |
| VPN/proxy left broken routes | Client | Error started after a VPN; tracert dies at hop one | Disconnect the VPN, reboot, reset the stack |
| IPv6 brokenness (AAAA without connectivity) | Client + owner | curl -6 -v fails while curl -4 -v works | User: disable IPv6; owner: remove the AAAA record or fix IPv6 |
| Private IP in the A record | Owner | dig A domain +short returns 192.168.x.x / 10.x.x.x | Replace the record with the server's public IP |
| Wrong static IP or gateway | Client | ipconfig /all: gateway empty or in another subnet | Switch to DHCP or correct the gateway address |
| Firewall blocks a subnet | Client / network | Error on some sites only; another network works | Review firewall and antivirus rules |
| Carrier filters addresses or IPv6 | Network | The site opens via another ISP or mobile data | Switch networks, report to the ISP |
How to diagnose the error with ping, tracert, curl, and dig
Step 1. Test reachability with ping
Confirm the internet works, then test the site over IPv4 and IPv6 separately:
ping 8.8.8.8
ping example.com
ping -4 example.com
ping -6 example.comIf ping 8.8.8.8 fails, the problem is your network or router — the website is irrelevant. If IPv4 works while IPv6 returns "General failure" or "Network is unreachable," you are looking at broken IPv6 connectivity.
Step 2. Find where the route breaks with tracert
# Windows
tracert example.com
# macOS / Linux
traceroute example.comA break at the first hop means packets never reach your router — check the VPN, firewall, or adapter settings. A break at hop two or three points at the router or ISP. If the trace dies inside the hosting network, the problem is server-side — a good moment to analyse packet loss and high ping.
Step 3. Compare IPv4 and IPv6 with curl
The key test for IPv6 brokenness — force the request over each protocol version:
curl -4 -v https://example.com/
curl -6 -v https://example.com/If curl -4 returns the page while curl -6 fails with "Network is unreachable," the site publishes an AAAA record part of its audience cannot reach. For background, see IPv4 vs IPv6.
Step 4. Inspect DNS records with dig
dig A example.com +short
dig AAAA example.com +shortThe A record must contain a public IP; keep the AAAA record only if the server is genuinely reachable over IPv6. Any address from 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16 in a public zone is a configuration error.
How to fix ERR_ADDRESS_UNREACHABLE as a user
- Reboot the router and the device. Power the router off for 30 seconds and wait for the WAN link to recover — this clears stuck sessions and refreshes the DHCP lease.
- Disable the VPN, proxy, and antivirus "traffic protection." If the error disappears, reinstall or update the VPN client — it was leaving broken routes behind.
- Reset the network stack. On Windows, run these commands as administrator and reboot:
netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns- Check the adapter settings. If the IP is set manually, switch to DHCP, or verify the gateway is correct and inside your subnet.
- Temporarily disable IPv6. If
curl -6fails whilecurl -4works, turn IPv6 off in the adapter properties — a workaround until your ISP or the site owner fixes connectivity. - Switch networks. Open the site over mobile data or another Wi-Fi. If it loads there, the fault is your ISP or LAN, not the website.
What should the site owner do?
- Audit your AAAA records. If the server has no working IPv6 (no address assigned, firewall closed, or the web server not listening on it), remove the AAAA record. Publishing AAAA "for the future" means part of your audience keeps hitting an unreachable address.
- Never publish private IPs. Public-zone A and AAAA records must contain public addresses only; keep internal addresses in a separate internal zone (split-horizon DNS).
- Test from multiple networks and protocols. Check the site over IPv4 and IPv6 and from another region — this error often reproduces only for a slice of the audience.
- Set up uptime monitoring. Regular checks from several regions catch a routing problem before users report it.
How to check your site online
Verify external reachability in seconds with Enterno tools: the Ping checker shows whether the server answers ICMP and whether TCP ports are open from outside, and the DNS lookup lists every A and AAAA record — private addresses and orphaned AAAA records become visible immediately. If the site is reachable externally but not from your machine, the problem is local.
Frequently asked questions
How is ERR_ADDRESS_UNREACHABLE different from ERR_NAME_NOT_RESOLVED?
With ERR_NAME_NOT_RESOLVED the failure is at the DNS stage: the browser could not turn the domain into an IP, so it has nowhere to connect. With ERR_ADDRESS_UNREACHABLE, DNS succeeded and the IP is known, but the OS found no route to it. The first error is about names; the second is about routing.
Why does the site open on my phone but not on my computer?
A phone on mobile data uses a different ISP, different routes, and often a different IP protocol version. If the computer's error comes from a VPN, a firewall, stale routes, or missing IPv6 at your home ISP, the mobile network does not share those problems. It is a reliable sign the site is alive and the cause is local.
Can a VPN cause ERR_ADDRESS_UNREACHABLE?
Yes — it is one of the most frequent causes. A VPN client adds its own routing-table entries, and after a dropped tunnel or unclean shutdown they can linger: the OS keeps sending packets through an interface that no longer exists. Disconnect the VPN, reboot, and reinstall the client if the problem returns.
What is IPv6 brokenness and how do I detect it?
It is when a domain has an AAAA record and the browser prefers IPv6, but no real IPv6 path exists between client and server. Detect it by comparing curl -4 -v and curl -6 -v: if IPv4 succeeds while IPv6 fails with "Network is unreachable," the diagnosis is confirmed. Fix it by removing the AAAA record or enabling IPv6 properly.
The error affects only some of my visitors. What should I check as the owner?
Start with dig A and dig AAAA: confirm the zone contains no private addresses and no dead AAAA records. Then test the site over both protocols from several networks and regions. Partial unreachability almost always points at IPv6 issues or geography-dependent routing rather than the web server itself.
Sources: the Chromium network error list net_error_list.h and MDN Web Docs.