ERR_NAME_NOT_RESOLVED: What It Means and How to Fix It

Chrome prints ERR_NAME_NOT_RESOLVED under the heading "This site can't be reached", usually next to the line "server IP address could not be found". The code is Chrome's label for internal network error -105. It means the browser asked for the address behind a hostname and did not get one it could use, so it never even tried to open a connection to the website.

That makes it a DNS symptom, not a web server symptom. Your job is to find which layer gave up: the browser, the operating system, a VPN, the router, the provider's resolver, or the domain's own records.

What the error code actually says

A hostname like www.example.com has to become an address such as 192.0.2.10 before any page can load. When that step fails, Chrome reports the failure rather than guessing. The -105 is simply the number Chromium's networking code assigns to "name not resolved". The label is broad: it covers a "name does not exist" answer, a timeout and a refused query.

How it differs from the other two DNS messages

Three messages cover most of this ground. They are close relatives: Chrome often follows a failed lookup with a diagnostic probe, and the message you see depends on what the probe concluded, the platform and the browser version. Treat the table as a guide.

For the wire-level meaning of the "name does not exist" answer, read NXDOMAIN explained. The code itself does not say who is at fault, so you test, cheapest question first.

First test: does the name resolve anywhere else?

Before changing a single setting, take a second device or network and open the same address. A phone on mobile data works well. If the site loads there, the problem sits in your own path. If it fails everywhere, the domain's DNS is the likely cause.

You can also query the name from outside your own network. Paste the hostname into the DNS lookup tool and check whether address records come back. The tool expects a full hostname such as www.example.com and rejects IP addresses and single-label names like intranet. No A or AAAA record means the problem is the domain; an address that comes back while Chrome still fails means it is local.

Fix it on desktop Chrome

Work through these from least to most invasive. Test the page after each one so you know which step mattered.

1. 1

   Retry in a private window

   Incognito starts without most extensions. If the site loads there, an ad blocker, privacy filter or VPN add-on is interfering; disable extensions one at a time.

2. 2

   Clear Chrome's host cache

   Open chrome://net-internals/#dns and use the Clear host cache button. Chrome keeps its own short-lived record of lookups, separate from the operating system. If the button is missing in your version, restarting Chrome clears the same cache.

3. 3

   Flush the operating system cache

   On Windows run ipconfig /flushdns in a terminal. On macOS the command depends on the version; a common one is sudo dscacheutil -flushcache followed by sudo killall -HUP mDNSResponder. The DNS cache flushing guide lists the variants, including Linux.

4. 4

   Check the hosts file

   A stale line in the hosts file overrides DNS completely. Look for the failing hostname in C:\Windows\System32\drivers\etc\hosts on Windows or /etc/hosts on macOS and Linux, and remove or comment out any line you did not add on purpose.

5. 5

   Turn off VPN, proxy and filtering software

   VPN clients and security suites often route DNS through their own resolvers. Disconnect and retest.

6. 6

   Try a different DNS server

   If your router or provider resolver is the weak link, set the adapter to a public resolver such as 1.1.1.1 or 8.8.8.8 and retest.

Chrome also has a Use secure DNS option under Settings, Privacy and security, Security. When it is on, Chrome can bypass the system resolver. If Chrome fails while a terminal lookup succeeds, toggling it separates the two paths.

Compare what the system and a chosen resolver say

These commands ask the same question of two resolvers. Replace the name with the one that fails.

nslookup www.example.com
nslookup www.example.com 1.1.1.1

# macOS or Linux, if dig is installed
dig www.example.com A +short
dig @1.1.1.1 www.example.com A +short

If the default resolver says the name does not exist but the public one returns an address such as 203.0.113.25, your default resolver is stale or filtering. If both fail, the domain's records are missing or its nameservers are not answering. The nslookup tool gives a third opinion from outside your network.

Fix it on Android

ERR_NAME_NOT_RESOLVED is common in Chrome on Android because the phone moves between Wi-Fi and mobile data. Menu names differ by manufacturer, so the paths below are typical.

1. Switch networks. Turn Wi-Fi off and load the page on mobile data, then the reverse. A site that works on one and fails on the other points at that network's resolver or router, not the phone.
2. Toggle airplane mode for ten seconds.
3. Check Private DNS. It is usually under Settings, Network and internet, Private DNS, though some phones place it under Connection or More connection settings. If it is set to a hostname that is mistyped or no longer working, every lookup fails. Set it to Automatic or Off to test.
4. Forget and rejoin the Wi-Fi network. This removes saved per-network settings such as a manual DNS entry.
5. Turn off any VPN or "DNS changer" app, and check Chrome's own Use secure DNS setting under Settings, Privacy and security.
6. Clear Chrome's cache in Android app settings if only Chrome fails.

Our Android-specific guide, how to flush DNS on Android, explains why a single "flush" button does not exist on most phones and what to do instead.

Fix it on iPhone and iPad

Chrome on iOS is built on Apple's web engine rather than the desktop Chrome networking stack, so the error page and its wording may not match the desktop one. If Chrome shows a DNS-style failure and Safari shows "Safari Can't Find the Server" for the same address, you are looking at the same failed lookup in two wrappers. If Safari loads the site and Chrome does not, the problem is inside Chrome.

1. Toggle Wi-Fi and cellular one at a time, then try airplane mode for about ten seconds.
2. Look at the Wi-Fi DNS setting. Open Settings, Wi-Fi, tap the info button next to your network, and look under Configure DNS. A manual entry that points at a dead server breaks every lookup on that network. Switch to Automatic, or enter a working resolver such as 1.1.1.1.
3. Check iCloud Private Relay. With an iCloud+ plan it sits under Settings, your name, iCloud, Private Relay. Turning it off for the current network is a quick way to rule it out.
4. Disconnect any VPN and look under Settings, General, VPN and Device Management for DNS or configuration profiles you do not recognize. A profile from a school, employer or filtering app can control DNS.
5. Reset network settings as a last step: Settings, General, Transfer or Reset iPhone, Reset, Reset Network Settings. This erases saved Wi-Fi passwords, cellular settings and VPN configurations, so note them first.

Pick the next step from the symptom

When the cause is on the domain's side

If nothing local changes the result, look at the domain itself. The usual suspects are an expired registration, nameservers that were changed at the registrar but not yet set up at the new host, or a missing www record while the bare domain works. A site that loads at example.com but not at www.example.com is a classic case: they are separate DNS entries.