ERR_ADDRESS_UNREACHABLE: what it means and how to fix it

What ERR_ADDRESS_UNREACHABLE means

By the time this error appears, DNS has already worked and the browser has an IP address. Chromium's error list describes ERR_ADDRESS_UNREACHABLE (code -109) as "The IP address is unreachable. This usually means that there is no route to the specified host or network." Chrome maps the operating system's own errors to it: EHOSTUNREACH ("No route to host") and ENETUNREACH ("Network is unreachable") on Linux, macOS, Android and ChromeOS, and WSAEHOSTUNREACH and WSAENETUNREACH on Windows.

The operating system raises those errors in three situations:

• No matching route. The routing table has no entry for the destination and no default gateway, so the connection fails at once with "Network is unreachable".
• The local network cannot find the host. The address is on your own subnet, but nothing answers the ARP request (Neighbor Discovery for IPv6) asking which device has it. After a few seconds of retries, the system gives up with "No route to host".
• A router or firewall says no. A device along the path sends back an ICMP "destination unreachable" message: host unreachable, network unreachable, or administratively prohibited. Linux turns each of these into "No route to host" or "Network is unreachable".

All three happen before a TCP connection exists, which is why this error usually appears at once or after a few seconds, not after the long wait of a timeout. If the name has several addresses, such as one IPv4 and one IPv6, Chrome tries the next address when one fails, so you only see the error when all of them failed.

ERR_ADDRESS_UNREACHABLE vs similar errors

Chrome names a failed page load after the first step that broke: the name lookup, the route to the address, then the TCP handshake. This error is the middle step. DNS worked, and something reported that the address cannot be reached before a connection could be set up.

Error	What happened at the network or protocol level	Where to look first
DNS_PROBE_FINISHED_NXDOMAIN	The lookup failed, then Chrome's probe resolved google.com through your DNS settings, so it blamed the name itself.	The spelling, then the domain's registration, delegation and records
ERR_NAME_NOT_RESOLVED	The lookup failed for any reason (no such name, no address record, a DNS server that failed or never answered), and no probe narrowed it down.	Compare your resolver's answer with a public resolver's
DNS_PROBE_FINISHED_BAD_CONFIG	Your configured DNS server failed the probe while Google Public DNS answered it.	DNS settings on the device, router or VPN; see DNS server not responding
ERR_ADDRESS_UNREACHABLE	DNS returned an address, but the operating system or a router reported there is no path to it ("No route to host").	Routes and VPN on your side, then firewalls that reject with ICMP
ERR_CONNECTION_TIMED_OUT	DNS and routing worked, but the TCP handshake got no reply before the timeout.	A firewall or security group that drops packets, or a server that is down
ERR_CONNECTION_REFUSED	The host answered the handshake with a TCP reset (or ICMP port unreachable): nothing accepted that port.	The web server process, its listen port, and REJECT firewall rules

One firewall can produce three of these errors depending on its rule. As a Linux or Android client sees it, a DROP rule gives a timeout, a REJECT with a TCP reset or ICMP port unreachable gives "refused", and a REJECT with ICMP host-prohibited or admin-prohibited gives this error.

How the error appears

Chrome shows "This site can't be reached" with ERR_ADDRESS_UNREACHABLE, one of the connection errors grouped under This site can't be reached. Command-line tools print the operating system's own wording:

curl -v https://192.168.1.50/
*   Trying 192.168.1.50:443...
* connect to 192.168.1.50 port 443 from 192.168.1.10 port 52814 failed: No route to host
curl: (7) Failed to connect to 192.168.1.50 port 443 after 3071 ms: Couldn't connect to server

ping 192.168.1.50
From 192.168.1.10 icmp_seq=1 Destination Host Unreachable

The delay of about three seconds, and a ping reply that comes "From" your own address, mean the ARP lookup on your local network failed: no device there has 192.168.1.50. Windows prints the same case as "Reply from 192.168.1.10: Destination host unreachable." When the message comes from a router's address instead, that router is the one reporting the problem, and traceroute marks it: !H for host unreachable, !N for network unreachable, !X for communication administratively prohibited.

What causes ERR_ADDRESS_UNREACHABLE

On the visitor's side:

• A private address from the wrong network. Addresses in 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 (RFC 1918) exist only inside the network that uses them. A bookmark for a NAS or a router page fails anywhere else, with this error or a timeout depending on your network.
• macOS local network privacy. On macOS 15 and later, an app needs Local Network permission to reach devices on your local network. If Chrome was denied it, local addresses such as your router's admin page fail with this error, while a browser that has the permission still loads them.
• VPN routes. A full-tunnel VPN can block access to your local network, and a split-tunnel VPN routes only the company ranges it was configured with, so an internal address outside them has no route.
• Guest Wi-Fi isolation. Guest and public networks often stop devices from reaching each other, so a printer or another laptop on the same Wi-Fi is unreachable.
• A half-working IPv6 connection. The device has an IPv6 address and route, but the network beyond it does not carry IPv6. Chrome usually falls back to IPv4; a site with only IPv6 addresses fails outright.
• Docker networks that overlap yours. Docker creates bridge networks in private ranges such as 172.17.0.0/16. If one overlaps an office, VPN or home subnet, traffic for those addresses goes into the Docker bridge and finds nothing.

On the server's side, where every visitor can be affected:

• A firewall that rejects with ICMP. firewalld, the standard firewall on RHEL, Fedora, Rocky Linux and AlmaLinux, rejects connections to ports you have not opened with an ICMP "prohibited" message, so Linux clients see "No route to host" rather than "Connection refused".
• A server that left its network. If the server is switched off, or its IP address was removed or moved during a migration or failover, the last router before it cannot find it and may answer "host unreachable" to every visitor.
• A DNS record with the wrong address. A private address published in the public zone, the address of a decommissioned server, or a AAAA record for IPv6 the server never had.

How it looks from the outside

A test from your own machine cannot tell a local routing problem from a server-side one. An HTTP check from many locations can, because it connects to the same address from networks that share nothing with yours:

• Every location succeeds and you fail. The cause is on your side: routes, VPN, Wi-Fi isolation, the macOS permission or your IPv6 path.
• Every location fails quickly. Something next to the server is rejecting connections: a firewall that answers with ICMP, or a last-hop router that cannot find the server.
• Every location times out. This is a different failure, where packets are dropped without any answer. Most cloud security groups behave this way, as does any firewall with a DROP rule; see the timeout row in the table above.
• Only some regions fail. A routing problem between those networks and the server's provider, or an IPv6 path that fails only for checks that connect over IPv6.

From your own side, a traceroute shows how far packets get: tracert -d 203.0.113.10 on Windows, traceroute -n 203.0.113.10 on macOS and Linux. The last hop that answers, and any !H, !N or !X mark next to it, shows which device refused to forward the packet.

How to fix it on your device

Start with the checks that apply everywhere. Look at the address: if it starts with 10., 192.168. or 172.16. to 172.31., it only works inside its own network or through a VPN into that network. Disconnect any VPN and retry. Restart the router to clear a stuck route. Then check the routing on the device itself.

Windows

Find-NetRoute -RemoteIPAddress 203.0.113.10
route print
Test-NetConnection 203.0.113.10 -Port 443
curl.exe -4 -I https://www.example.com
curl.exe -6 -I https://www.example.com

Find-NetRoute shows the interface and next hop Windows would use for that address. An error, or a VPN adapter you did not expect, is the problem. Type curl.exe rather than curl, because in Windows PowerShell 5.1 curl is an alias for Invoke-WebRequest. If IPv4 works and IPv6 fails, clear Internet Protocol Version 6 (TCP/IPv6) in the adapter's properties (Control Panel, Network Connections) as a test, and report the IPv6 fault to your provider rather than leaving it off.

macOS

1. For local addresses (a router, NAS, printer, or a dev server on another machine), open System Settings, Privacy & Security, Local Network, and turn on Google Chrome. Quit and reopen Chrome.
2. Check the route with route -n get 203.0.113.10. It prints the interface and gateway, or "not in table" when there is no route.
3. Compare curl -4 -I https://www.example.com with curl -6 -I https://www.example.com to isolate an IPv6 problem.

Linux

ip route get 203.0.113.10
ip -6 route show default
ip neigh show

ip route get prints the route the kernel would use, or an error ending in "Network is unreachable" if there is none. A FAILED entry in ip neigh show is a local host that never answered ARP. If ip route sends the range you are trying to reach to a docker0 or br- interface, a Docker network is in the way.

Android

Switch between Wi-Fi and mobile data, and pause VPN and firewall apps. A private address only works on the network it belongs to, so a home NAS bookmark fails on mobile data unless you connect through a VPN into your home network.

Server-side causes and configuration

Firewalls that reject with ICMP

On firewalld systems, see which zone the public interface is in and what it allows, then open the service the site uses:

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=public --list-all
sudo firewall-cmd --zone=public --add-service=https --permanent
sudo firewall-cmd --reload

With plain iptables, the reject type in the rule decides what clients report. iptables checks rules in order, so the ACCEPT has to come first:

# allow HTTPS
-A INPUT -p tcp --dport 443 -j ACCEPT
# reject everything else with ICMP host-prohibited: "No route to host" on Linux clients
-A INPUT -j REJECT --reject-with icmp-host-prohibited
# or with a TCP reset instead: "Connection refused"
# -A INPUT -p tcp -j REJECT --reject-with tcp-reset

A server that is no longer on its address

If every location fails and the last traceroute hop is your provider's router, confirm the server still holds its public address, especially after a migration or a failover:

ip -br addr show
ip route show default

Cloud servers usually hold only a private address and reach the internet through the provider's NAT, so the public IP will not appear in that output. Check in the provider's console that it is still attached to the instance.

DNS records that point nowhere

dig +short A www.example.com
dig +short AAAA www.example.com
curl -4 -sv -o /dev/null https://www.example.com
curl -6 -sv -o /dev/null https://www.example.com

Every address returned must be public and live. A zone that leaked an internal address looks like this:

; wrong: the internal address of the app server
app   300  IN  A  10.0.4.21
; right: the public address of the load balancer in front of it
app   300  IN  A  203.0.113.10

If curl -6 fails while curl -4 works, fix the server's IPv6 configuration or remove the AAAA record, because visitors with IPv6 usually try that address first. Once the IPv6 path works, make sure the web server also listens on it. In nginx that is listen [::]:443 ssl;, and without it the IPv6 attempt is refused rather than unreachable.

Docker address ranges

On a server or laptop running Docker, a bridge network can claim a range that your office, your VPN or a backend behind your proxy also uses. Move Docker's ranges to space you do not use, in /etc/docker/daemon.json:

{
  "bip": "10.200.0.1/24",
  "default-address-pools": [
    { "base": "10.201.0.0/16", "size": 24 }
  ]
}

Restart Docker afterwards. User-defined networks that already exist keep their old subnet until you remove and recreate them.

How to prevent ERR_ADDRESS_UNREACHABLE

A DNS record that starts pointing at a private or retired address, or a firewall rule that rejects every visitor, leaves nothing in the web server's logs, because no request reaches it. A check that connects to the site from outside on a schedule sees the failure on its next run. HostTracker has monitored websites since 2004, runs checks from 300+ checkpoints in 158 cities and sends alerts by email, SMS, voice call, Slack, Telegram and more.

Frequently asked questions

Is ERR_ADDRESS_UNREACHABLE the same as the site being down?

Usually not. It most often points at a routing problem on your own network or device, especially with a private address or IPv6. It can mean the server is down when the server's last router answers "host unreachable" for it, and then a check from other locations fails the same way.

Why do I only see this error on certain Wi-Fi networks?

Networks have different routes, VPN settings and isolation rules. A route that works at home may not exist on a corporate or public network, which mostly affects internal addresses. Guest networks also often block traffic between devices.

Can a firewall cause ERR_ADDRESS_UNREACHABLE?

Yes. A firewall that rejects with ICMP host-prohibited or admin-prohibited, which firewalld does by default for ports you have not opened, produces "No route to host" on Linux and Android clients. A firewall that drops packets produces a timeout instead, and one that rejects with a TCP reset produces a refused connection.

What is the difference between this and ERR_CONNECTION_TIMED_OUT?

ERR_ADDRESS_UNREACHABLE means something reported that no path exists, so the attempt ends quickly. ERR_CONNECTION_TIMED_OUT means the connection attempt went out and nothing answered before the wait expired.

Why can't Chrome on my Mac open my router's admin page?

On macOS 15 and later, check System Settings, Privacy & Security, Local Network, and make sure Google Chrome is turned on. Without that permission, Chrome cannot reach any address on your local network, including the router.

How do I check if an address is private?

Look at the first part of the IP address: 10.0.0.0 through 10.255.255.255, 172.16.0.0 through 172.31.255.255, and 192.168.0.0 through 192.168.255.255 are reserved for private networks by RFC 1918 and are not routed on the public internet.

Sources and further reading

• Chromium net error list, the definition of ERR_ADDRESS_UNREACHABLE (-109).
• RFC 1918, Address allocation for private internets.
• firewalld.zones man page, including the icmp-host-prohibited rejection.
• Apple TN3179: Understanding local network privacy, the macOS 15 and iOS permission.