ERR_NETWORK_CHANGED: what it means and how to fix it

What ERR_NETWORK_CHANGED means

Chromium defines NETWORK_CHANGED (-21) as "The network changed." Chrome listens to the operating system for network changes: a new IP address on an interface, an interface that appears or disappears, a switch between Wi-Fi, cable and mobile data. When the system reports an IP address change, the network stack of Chrome cleans up. In the Chromium source, it cancels connection attempts that are still in progress, closes idle sockets, and closes or retires its open HTTP/2 and QUIC sessions. Requests that depended on a canceled attempt or a closed connection fail with ERR_NETWORK_CHANGED.

The background is how TCP works. RFC 9293 identifies a connection by the addresses and ports at both ends, so after the local address changes, the old connections cannot carry data any more. Canceling them at once lets the next attempt start cleanly on the new network instead of waiting for a timeout.

The trigger is a message from the operating system, not a measurement of the connection. The Internet can work again a second later. A VPN client that adds a virtual adapter can fire the event while your page is loading, and that is why a plain reload usually works. Requests that already hold a plain HTTP/1.x connection are not part of that cleanup. They continue, or fail by themselves if the old address stopped working.

How the error appears

Chrome shows "Your connection was interrupted" with the text "A network change was detected" and the code ERR_NETWORK_CHANGED, plus a Reload button. Edge, Brave, Opera and other Chromium browsers show the same page.

Developers meet it in the DevTools console and in code. A fetch() call that is canceled this way rejects with a TypeError, and the console line looks like this:

GET https://example.com/api/items net::ERR_NETWORK_CHANGED
Uncaught (in promise) TypeError: Failed to fetch

To see your own network changes as they happen on Linux, run ip monitor address. It prints a line each time an address is added, and a line that starts with "Deleted" each time one is removed. If a line appears every time Chrome shows the error, you have found the trigger.

ERR_NETWORK_CHANGED vs similar errors

Chrome shows several of these under the heading "This site can't be reached", so the code underneath is what tells them apart. The numbers are Chromium's internal error codes.

Error	What happened at the network or protocol level	Where to look first
ERR_NETWORK_CHANGED (-21)	The operating system reported a network or IP address change, and Chrome canceled the requests that were in flight.	VPN clients, Wi-Fi roaming, virtual adapters, adapter power settings.
ERR_INTERNET_DISCONNECTED (-106)	The operating system reports that the Internet connection has been lost.	Wi-Fi or cable, airplane mode, the router.
ERR_NETWORK_ACCESS_DENIED (-138)	Permission to use the network was denied, which Chromium says is most likely caused by a firewall.	The firewall or security software, and whether Chrome is allowed through it.
ERR_ADDRESS_UNREACHABLE (-109)	The operating system or a router reported that there is no route to the IP address.	Routing on the client side: VPN routes, the local network, IPv6 setup.
ERR_NAME_NOT_RESOLVED (-105)	The DNS lookup returned no usable IP address, so no connection was attempted.	The DNS records of the domain and the resolver of the device.
ERR_CONNECTION_TIMED_OUT (-118)	The SYN went out and nothing came back until the client gave up.	Firewalls that drop packets, and whether the host is up.

What causes ERR_NETWORK_CHANGED

• Switching networks. Moving from Wi-Fi to a mobile hotspot, from one access point to another, or from Wi-Fi to a cable gives the device a new address.
• A VPN connecting or disconnecting. The client adds or removes a virtual adapter and changes the routes. A client that reconnects on its own repeats this every time.
• Virtual adapters from other software. Virtual machine and container tools (Hyper-V, VirtualBox, VMware, WSL, Docker) create adapters that can appear, disappear or change address while you browse.
• IPv6 changes. IPv6 addresses and routes can be added or removed when a router restarts or sends new prefixes, or when you turn IPv6 on or off for an adapter.
• A new address from DHCP. A device that wakes from sleep, or a router that restarts, can get a new local address.
• An unstable adapter. A weak Wi-Fi signal that drops and reconnects, a loose cable, a faulty driver, or a power-saving setting that switches the adapter off.
• Several network tools at once. Two VPN clients, a security suite and a network manager can change interfaces back and forth.

Fixes for the visitor

Try these steps on every system first, then use the section for your system.

1. Wait a few seconds and reload. After the change, the next request uses the new network.
2. Connect the VPN first, then load pages. If the error appears each time the VPN connects, wait until it shows "connected" before you open the site.
3. Stay on one network while a page or a download is loading. Do not turn Wi-Fi off and on, and do not move between access points in the middle of a transfer.
4. Reset Chrome's connections. Open chrome://net-internals/#sockets and click "Close idle sockets" and "Flush socket pools". On the "DNS" tab, click "Clear host cache".
5. Restart the router if the error comes back every few minutes.

Windows

Open an administrator Command Prompt, run these commands, and restart the computer:

ipconfig /release
ipconfig /renew
ipconfig /flushdns
netsh winsock reset
netsh int ip reset

List the adapters in PowerShell with Get-NetAdapter. Disable adapters that belong to virtual machine or VPN software you do not use in ncpa.cpl, the Network Connections window (press Win+R and type the name). For a Wi-Fi adapter that turns itself off, open Device Manager, double-click the adapter, and on the "Power Management" tab clear "Allow the computer to turn off this device to save power". As a test, you can also clear "Internet Protocol Version 6 (TCP/IPv6)" in the properties of the adapter. If the error stops, the IPv6 setup of your router or provider is the likely cause. A newer driver from the maker of the adapter is the last step to try.

macOS

Switch the Wi-Fi adapter off and on again from Terminal. The device name is often en0, but check it first:

networksetup -listallhardwareports
networksetup -setairportpower en0 off
networksetup -setairportpower en0 on
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Remove VPN profiles and virtual network services that you no longer use in System Settings > Network.

Linux

nmcli radio wifi off && nmcli radio wifi on
sudo systemctl restart NetworkManager
resolvectl flush-caches

Use ip monitor address to watch for address changes while you reproduce the error. If addresses keep changing without any action from you, look at the logs of the network manager (journalctl -u NetworkManager) and at what else runs on the machine, such as VPN clients and container tools.

Android and ChromeOS

Turn airplane mode on and off, then forget the Wi-Fi network and join it again. If the error comes back only on one Wi-Fi network, try another network or mobile data to find out whether the access point is at fault. On a phone with a VPN app, wait until the VPN shows as connected before you open pages.

What site owners and developers can do

You cannot stop the network of a visitor from changing, and there is nothing on your server to fix. You can make the site and the app recover when a request is canceled this way.

• Retry idempotent requests. GET, PUT and DELETE can be sent again safely. RFC 9110 explains that idempotent methods are the ones a client may repeat automatically after a communication failure.
• Protect POST requests with an idempotency key. The client sends a unique key with the request, and the server returns the stored result when it sees the same key again. The retry then cannot create a second order.
• Make large uploads and downloads resumable. Send files in chunks that can be repeated, and support range requests (Range and Accept-Ranges) so that a download continues where it stopped.
• Reconnect long-lived connections. WebSocket and server-sent event clients need reconnect logic with a growing delay.

async function fetchWithRetry(url, options = {}, tries = 3) {
  for (let attempt = 1; ; attempt++) {
    try {
      return await fetch(url, options);
    } catch (err) {
      // Network failures such as ERR_NETWORK_CHANGED reject with a TypeError.
      if (attempt >= tries) throw err;
      await new Promise(resolve => setTimeout(resolve, 500 * attempt));
    }
  }
}

Use this wrapper only for requests that are safe to repeat. On the server, a request that the client abandons usually shows up as a 499 in the access log of nginx, which is not a server error. The 499 Client Closed Request guide explains how to read these entries.

How it looks from the outside

A monitoring check runs from fixed servers, so it never changes networks and cannot reproduce this error. That is also what makes a check useful here: it shows whether the site itself behaved normally while a visitor saw the error.

• Normal from every checkpoint, error on one device: the cause is on that device or its network.
• Reports from mobile or roaming users only: their networks change often. Look at the code in the app or the page, and add retries.
• Reports from many users on one network or provider at the same time: a router, an access point or the provider may be restarting. Your site is probably unaffected.
• Slow or failing responses from the checkpoints too: this is a separate problem on your side, and visitors would see other error codes, such as a timeout or a reset.

The ping test pings a website, server or IP address from 300+ locations in one click and measures the latency from the checkpoints to your host, not from your own connection. If the host answers normally there while your device keeps failing, the problem is local.

What monitoring shows when visitors report it

When several people write that the site "keeps interrupting", compare their reports with the results of your monitoring for the same time. HostTracker checks websites from 300+ checkpoints in 158 cities and sends alerts by email, SMS, voice call, Slack, Telegram and more. Checks that stayed green during the reports show that the cause was on the side of the visitors.

Frequently asked questions

Is ERR_NETWORK_CHANGED a problem with the website?

Almost never. The error comes from the browser and the network of the visitor, which a site does not control. A site can still recover from it with retries.

Why does it appear when I connect to a VPN?

A VPN adds a virtual adapter and changes the routes. The operating system reports this as a network change, and Chrome cancels the requests that were running at that moment. Reload after the VPN shows that it is connected.

Why does it come back every few minutes?

Something keeps changing your network. Typical reasons are a Wi-Fi signal that drops, an adapter that powers itself down, a VPN that reconnects, or two network tools that compete for the same adapter. Watch the changes with ip monitor address on Linux or check the adapter list on Windows with Get-NetAdapter.

Does it mean my Internet is down?

No. In most cases the Internet works again within seconds. If it does not, you will usually see ERR_INTERNET_DISCONNECTED or a timeout instead.

Will disabling IPv6 fix it?

Sometimes, when the IPv6 addresses or routes of your network keep changing. Treat it as a test. If it helps, fix the IPv6 configuration of the router and turn IPv6 on again.

Will clearing the browser cache help?

No. The error is about connections and not about stored files. The "Flush socket pools" button in chrome://net-internals is the closest thing to a fix inside the browser.

Why do large downloads fail with it?

A long transfer has more time to meet a network change. A download manager or a site that supports range requests can continue where the transfer stopped. A plain browser download usually has to start again.

Sources and further reading

• Chromium net error list: the definitions of NETWORK_CHANGED (-21) and the other codes in the table above.
• Chromium: transport_client_socket_pool.cc: what the socket pools do when the IP address changes (OnIPAddressChanged).
• RFC 9110, HTTP Semantics: section 9.2.2 on idempotent methods and automatic retries, and section 14 on range requests.
• Microsoft: ipconfig: the /release, /renew and /flushdns options.