How to Fix ERR_ADDRESS_UNREACHABLE in Chrome

Network Intermediate 7 min read Published July 17, 2026

What Is ERR_ADDRESS_UNREACHABLE?

ERR_ADDRESS_UNREACHABLE is a Chrome network error that appears when your browser cannot reach the destination IP address at all. It is fundamentally different from ERR_CONNECTION_REFUSED, where a machine answers but no service is listening, and from ERR_CONNECTION_TIMED_OUT, where packets simply disappear without a response. With ERR_ADDRESS_UNREACHABLE, the network itself is telling Chrome that the destination cannot be reached.

The underlying signal is usually an ICMP "Destination Unreachable" message (type 3) generated by a router — or by your own machine's network stack — and returned to the browser. Because the failure happens below the application layer, the web server on the other end may be perfectly healthy; the problem lies in the path between you and it. A network interface may be down, a route may be missing, a firewall may be blocking an entire subnet, or the ARP cache may hold a stale hardware address.

The six steps below walk through the most common causes in the order you are most likely to encounter them, from the simplest local checks to deeper routing and ARP issues.

Common Causes

ERR_ADDRESS_UNREACHABLE almost always traces back to one of these six root causes. Use this table as a quick orientation before you start diagnosing.

Root Cause	Typical Scenario	Where to Look
Network interface down	Wi-Fi dropped, cable unplugged, VPN tunnel collapsed	OS network status, `ipconfig` / `ip addr`
Destination host offline	The target IP does not respond to any traffic	`ping` the target IP
Firewall blocking the subnet	OS or cloud firewall drops the whole IP range	ufw, firewalld, security groups
Missing or wrong route	No route to the destination network in the routing table	`route print`, `ip route`
VPN or proxy misrouting	Traffic is sent into a dead tunnel or wrong gateway	VPN client, system proxy settings
Stale ARP cache	Cached MAC address no longer matches the real device	`arp -a`, `arp -d`

Step 1: Check Your Network Connection

Before chasing exotic routing problems, confirm the basics: is your machine actually online, and is the correct interface active? A dropped Wi-Fi connection, a disconnected Ethernet cable, or a VPN tunnel that collapsed in the background are the most frequent — and most embarrassing — causes of ERR_ADDRESS_UNREACHABLE.

# Windows
ipconfig /all

# Linux
ip addr show

# macOS
ifconfig

Look for an interface with a valid IP address and an active link. If your primary interface is down or holds an APIPA address (169.254.x.x on Windows), the OS has no usable route to anything, and every destination is "unreachable." Reconnect to the network, restart the interface, or reconnect the VPN before going further.

Step 2: Ping the Target IP Address

Once your own connectivity is healthy, test whether the destination IP itself is reachable. Pinging the IP strips DNS out of the equation so you can isolate a routing or reachability problem from a name-resolution problem.

# Ping by IP (Windows sends 4 by default; Linux pings until Ctrl+C)
ping 203.0.113.10

# On Linux/macOS, limit the count
ping -c 4 203.0.113.10

If ping returns "Destination host unreachable," the failure is in routing or the local network — move on to the firewall and routing steps. If it returns "Request timed out," the path exists but the host is not responding (it may be offline or dropping ICMP), which is a different problem. If ping by IP succeeds but the browser still fails, the issue is higher up: check whether DNS resolved to the wrong IP.

Step 3: Check Firewall Rules

A firewall configured to drop an entire subnet or IP range will make the destination look unreachable. This is especially common with cloud security groups and corporate endpoint protection. Inspect the firewall on both your machine and the destination:

# Windows Firewall
netsh advfirewall firewall show rule name=all | findstr "203.0.113"

# ufw (Ubuntu)
sudo ufw status verbose

# firewalld (CentOS/RHEL)
sudo firewall-cmd --list-all

# iptables
sudo iptables -L -n

Look for REJECT or DROP rules that cover the destination IP or its subnet. On cloud platforms (AWS, Azure, GCP), remember that security groups act as a second firewall — a blocked subnet there produces the same unreachable symptom. Temporarily allow the destination IP and test again.

Step 4: Verify the Routing Table

If no firewall is to blame, the next suspect is the routing table. ERR_ADDRESS_UNREACHABLE frequently appears when there is no valid route to the destination network — for example, after a VPN disconnects and leaves a broken default route, or when a static route was never added. Inspect the active routes:

# Windows
route print

# Linux
ip route show

# macOS
netstat -rn

Identify the default route (the 0.0.0.0 entry on Windows/Linux) and confirm it points to a live gateway. Trace the exact path Chrome's traffic would take to the destination:

# Linux: ask the kernel which route it would use
ip route get 203.0.113.10

If the command reports "Network is unreachable" or points to a dead gateway, you have found the cause. Add or repair the route — for example, restore a missing default route or re-add a static route to the destination subnet.

Step 5: Check VPN and Proxy Settings

VPNs and proxies rewrite where your traffic goes, which makes them a leading cause of sudden "unreachable" errors. A VPN client that crashed without cleaning up can leave a default route pointing into a tunnel that no longer exists, so every packet is sent into a void. Likewise, a proxy configured to forward to an offline gateway will make destinations unreachable.

# Check proxy environment variables
echo $http_proxy $https_proxy $all_proxy

# Windows: list active proxy settings
netsh winhttp show proxy

On Windows, open Settings > Network & Internet > Proxy and disable any manual proxy that is no longer valid. If a VPN is involved, fully disconnect and reconnect it, or disable it temporarily to see whether reachability returns. A split-tunnel VPN that does not include the destination subnet will also produce this error.

Step 6: Flush the ARP Cache

ARP (Address Resolution Protocol) maps IP addresses to MAC addresses on your local network. If a device's IP address changes but your machine still holds the old MAC address in its ARP cache, traffic to that IP goes to the wrong hardware address and the destination appears unreachable. This is common after replacing a router, reassigning IPs, or failing over to a new gateway.

# View the ARP cache
arp -a

# Windows: flush the entire ARP cache
arp -d *

# Linux/macOS: delete a specific entry
sudo ip neigh del 203.0.113.1 dev eth0
# macOS
sudo arp -d 203.0.113.1

After flushing, the next connection forces a fresh ARP request and rebuilds the mapping with the correct MAC address. If reachability returns immediately after clearing the ARP cache, a stale hardware address was the culprit — consider shortening the ARP cache timeout on systems where IPs change frequently.

Network Diagnostic Commands

These commands form a complete reachability toolkit. Run them in order to pinpoint exactly where the path to the destination breaks.

# 1. Test basic reachability to the destination IP
ping -c 4 203.0.113.10          # Linux/macOS
ping 203.0.113.10               # Windows

# 2. Trace each hop to find where packets stop
traceroute 203.0.113.10         # Linux/macOS
tracert 203.0.113.10            # Windows

# 3. Inspect active connections and listening ports
netstat -rn                     # routing table (all OSes)
sudo netstat -tlnp              # listening TCP ports (Linux)

# 4. Examine and manage the ARP cache
arp -a                          # view cache (all OSes)
arp -d *                        # flush cache (Windows)
sudo ip neigh flush all         # flush cache (Linux)

If traceroute stops responding at a particular hop, that hop is where reachability breaks — often a firewall, a dead gateway, or the boundary of a VPN tunnel. Combine this with the routing-table check from Step 4 to confirm whether your machine even has a route to that hop.

Quick Reference: Causes and Fixes

Symptom	Root Cause	Fix
"Destination host unreachable" immediately	No route to the network	Check `route print` / `ip route`; repair default route
Only fails after VPN disconnect	Broken tunnel route left behind	Reconnect or fully disable the VPN
Fails on one subnet only	Firewall dropping the IP range	Allow the subnet in ufw/security groups
Works, then stops after device swap	Stale ARP cache entry	Run `arp -d` to flush the cache
APIPA address (169.254.x.x)	No DHCP lease / interface down	Reconnect network or restart interface
ping by IP works, browser fails	DNS resolved to wrong IP	Flush DNS; verify resolved IP

Frequently Asked Questions

Is ERR_ADDRESS_UNREACHABLE the same as ERR_CONNECTION_REFUSED?

No. ERR_CONNECTION_REFUSED means a machine answered but no service is listening on the port. ERR_ADDRESS_UNREACHABLE means the network cannot deliver packets to the destination IP at all — no machine even gets a chance to respond. They require completely different fixes.

Why does only one website show this error?

When a single destination is unreachable but others work, the cause is usually specific to that IP's path: a firewall rule blocking its subnet, a stale ARP entry for its gateway, or a route that covers only that network. Use traceroute to find where the path to that specific IP breaks.

Can a VPN cause ERR_ADDRESS_UNREACHABLE?

Yes, frequently. A VPN that crashes without cleaning up can leave a default route pointing into a dead tunnel, making every destination unreachable. A split-tunnel VPN that excludes the destination subnet will make just that subnet unreachable. Fully disconnect and reconnect the VPN, or disable it to test.

Will flushing the ARP cache always fix it?

Only when a stale MAC address is the cause — typically after a router or NIC swap on your local segment. If the problem is a missing route or a firewall block, flushing ARP will not help. Use the diagnostic commands above to confirm the ARP cache is the culprit before relying on it.

Conclusion

ERR_ADDRESS_UNREACHABLE is a routing-level failure: Chrome cannot deliver packets to the destination IP, regardless of whether the server itself is healthy. Work through the six steps in order — verify your own connection, ping the target, check firewalls, inspect the routing table, review VPN and proxy settings, and flush the ARP cache — and you will almost always find the break in the path. The diagnostic commands give you a repeatable way to pinpoint the exact hop where reachability is lost, so you can fix the real cause rather than guessing.