How to fix ERR_NAME_NOT_RESOLVED in Chrome?

ERR_NAME_NOT_RESOLVED is Chrome's error for "I couldn't find an IP address for this website's name". To fix it, first check the address for typos and confirm the site loads on another device or network. If it's only Chrome on your computer, clear Chrome's host cache at chrome://net-internals/#dns, check the Use secure DNS setting, disable extensions that filter traffic, and turn off Preload pages. If other apps are affected too, flush your system's DNS cache and change your DNS server. If the site fails everywhere, the domain's DNS records are broken and only the site owner can fix them.

Chrome has its own DNS machinery, its own cache, and settings that can quietly route lookups away from your operating system. That's why ERR_NAME_NOT_RESOLVED sometimes appears in Chrome while Firefox or a terminal command resolves the same name perfectly. This guide focuses on Chrome itself: how it resolves names, where it can go wrong, how to capture a log that shows exactly what happened, and a few developer-specific traps such as router rebinding protection and local hostnames.

What ERR_NAME_NOT_RESOLVED Means

Chrome reports network failures with internal error codes. ERR_NAME_NOT_RESOLVED (error code -105) is the general code for a failed hostname lookup. It covers several underlying situations:

• The DNS server answered that the name doesn't exist (NXDOMAIN).
• The DNS server returned no usable address.
• The DNS lookup failed in a way that couldn't be classified more precisely.

When the main page fails to load, Chrome can run a follow-up DNS probe and replace the code with a more specific one, such as DNS_PROBE_FINISHED_NXDOMAIN or DNS_PROBE_FINISHED_NO_INTERNET. You're more likely to see the plain ERR_NAME_NOT_RESOLVED when the probe is inconclusive, on Android, or in the browser's developer tools when a subresource fails. For example, if an image, script or API call on a page points at a hostname that doesn't resolve, the Console and Network tabs show:

GET https://cdn.example.net/app.js net::ERR_NAME_NOT_RESOLVED

That last case is worth knowing if you're a developer: the page loads, but a broken asset hostname silently breaks part of it.

How Chrome Resolves Names

Understanding where Chrome gets its answers makes the fixes logical. Depending on your platform and settings, Chrome may use:

1. Its own in-memory host cache: Recently resolved names, including recent failures, kept for a short time.
2. Its built-in DNS client: On many platforms Chrome reads your system's DNS server settings and hosts file, then sends queries itself.
3. The operating system's resolver: Chrome falls back to this, and uses it in situations its own client can't handle.
4. Secure DNS (DNS over HTTPS): If enabled, Chrome sends queries over HTTPS to a supported provider instead of plain DNS.

Because of this, Chrome can disagree with other apps. A stale entry in Chrome's cache, or a Secure DNS provider that's blocking or failing a domain, affects Chrome and not much else.

Step 1: Rule Out the Obvious

1. Check the URL: Look for typos, missing letters, or the wrong domain ending.
2. Try another network: Load the site on your phone using mobile data.
3. Try another browser: If Firefox or Safari loads the site on the same computer, the problem is specific to Chrome.
4. Test from the command line: This bypasses Chrome entirely.

nslookup www.example.com

If the command line resolves the name but Chrome doesn't, start with Chrome's settings below. If the command line fails too, the problem is your system's DNS or the domain itself.

Step 2: Clear Chrome's Host Cache and Socket Pools

Chrome caches negative results too. If it looked up a name during a brief outage, it can keep failing after the outage ends.

1. Open chrome://net-internals/#dns.
2. Click Clear host cache.
3. Open chrome://net-internals/#sockets.
4. Click Close idle sockets, then Flush socket pools.
5. Reload the page with Ctrl+Shift+R (Windows and Linux) or Cmd+Shift+R (macOS).

The DNS page also has a lookup box. Enter the hostname and click Resolve to see what Chrome's resolver returns right now, without loading the page:

Resolved IP addresses of "www.example.com": ["192.0.2.10","2001:db8::10"].
No alternative endpoints found.

If you get an error here while the command line works, the problem is inside Chrome.

Step 3: Check the Secure DNS Setting

Chrome's Use secure DNS option sends lookups over encrypted HTTPS. It's a good privacy feature, but it's also a common cause of Chrome-only resolution failures, because Chrome is no longer using the same DNS server as the rest of your system.

1. Go to chrome://settings/security.
2. Scroll to Use secure DNS.
3. Note the current setting, then try one of these:
   • Switch it off and reload the page.
   • Change Select DNS provider to a different provider, such as Cloudflare (1.1.1.1) or Google (Public DNS).

If the site loads with Secure DNS off, the previous provider was blocking or failing to resolve the domain. Some filtering DNS providers return NXDOMAIN for categories they block.

On managed work devices, Secure DNS may be controlled by your administrator. You can see which policies are applied at chrome://policy. Look for DnsOverHttpsMode and DnsOverHttpsTemplates.

Step 4: Disable Extensions That Touch Network Traffic

Ad blockers, privacy tools, VPN extensions and proxy extensions can all interfere with DNS or block requests to specific hostnames.

1. Open an Incognito window (extensions are disabled there by default unless you've allowed them).
2. Visit the site.
3. If it works in Incognito, go to chrome://extensions and disable extensions one at a time until you find the culprit.

VPN and proxy extensions are the most likely offenders, because they route traffic through their own servers and resolvers.

Step 5: Turn Off Page Preloading

Chrome's Preload pages feature can resolve and fetch pages in advance. It doesn't usually cause ERR_NAME_NOT_RESOLVED by itself, but when you're troubleshooting, switching it off removes one variable and stops Chrome making extra background lookups that clutter your logs.

1. Go to chrome://settings/performance (on some versions, chrome://settings/preloading).
2. Turn off Preload pages.

Step 6: Fix System-Level DNS

If the command line also fails, the problem is beneath Chrome. Flush your operating system's DNS cache:

# Windows, as administrator
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux with systemd-resolved
resolvectl flush-caches

Then check your hosts file for entries that override the site:

# macOS and Linux
grep -i "example.com" /etc/hosts

# Windows
Select-String -Path C:\Windows\System32\drivers\etc\hosts -Pattern "example.com"

If your system's DNS server is unreliable, switch to a public resolver such as 1.1.1.1 or 8.8.8.8 in your network settings or router.

Step 7: Fix Chrome on Android

ERR_NAME_NOT_RESOLVED is particularly common on Android. Work through these:

1. Clear Chrome's host cache: Visit chrome://net-internals/#dns in Chrome on your phone and tap Clear host cache.
2. Check Private DNS: Go to Settings > Network & internet > Private DNS (the exact path varies by manufacturer). If it's set to a specific hostname, that provider handles every lookup on your phone. Switch to Automatic or Off to test. If the configured hostname is wrong or unreachable, every DNS lookup fails.
3. Toggle airplane mode: This resets the network connection and clears the system DNS cache.
4. Clear Chrome's data: Go to Settings > Apps > Chrome > Storage and clear the cache.
5. Try mobile data instead of Wi-Fi: This tells you whether the Wi-Fi network's DNS is the problem.

Step 8: Capture a Network Log

If you can't find the cause, Chrome can record exactly what happened during the lookup. This is invaluable for stubborn problems or for sending to IT support.

1. Open chrome://net-export in a new tab.
2. Click Start Logging to Disk and choose where to save the file.
3. In another tab, try to load the failing site.
4. Return to the net-export tab and click Stop Logging.

The log is a JSON file. You can open it in the netlog viewer that Chrome's developers publish, or search it directly. Look for events with HOST_RESOLVER in their name and the hostname you tried. Each attempt records which resolver Chrome used (system, built-in, or secure DNS) and the error it got back, which tells you immediately which layer failed.

Be aware that the log contains the URLs you visited during the capture. Only share it with people you trust.

For Developers: Common Traps

If you build websites, a few scenarios produce ERR_NAME_NOT_RESOLVED that have nothing to do with the public DNS.

Router DNS Rebinding Protection

Many routers and filtering resolvers block DNS answers that point a public domain name at a private IP address, such as 192.168.x.x or 10.x.x.x. This protects against DNS rebinding attacks, but it also breaks legitimate setups such as:

• A public hostname that resolves to a server on your local network.
• Wildcard services that map names to private IPs for local development.

You can confirm it by comparing your router's answer with a public resolver:

dig @192.168.1.1 dev.example.com +short
dig @1.1.1.1 dev.example.com +short

(no output from the router)
10.0.0.25

If the public resolver returns a private address and your router returns nothing, rebinding protection is stripping the answer. Most routers let you whitelist specific domains. For dnsmasq-based routers, that's the rebind-domain-ok option:

# /etc/dnsmasq.conf
stop-dns-rebind
rebind-domain-ok=/dev.example.com/

Local Hostnames

Names that only exist on your machine, such as entries in the hosts file or names served by a local DNS tool, can behave differently in Chrome depending on its resolver and Secure DNS setting. If a local name fails in Chrome but works with ping, try turning Secure DNS off.

Chrome resolves localhost and any name ending in .localhost to the loopback address itself, without asking DNS. If you're using a different made-up domain for development, consider switching to .localhost subdomains, such as app.localhost, which work without any hosts file entries.

Broken Subresource Hostnames

If the page loads but parts are missing, open DevTools (F12), go to the Network tab, reload, and filter by ERR_NAME_NOT_RESOLVED. Every failing request shows its hostname. Typical culprits are an old CDN hostname, a typo in an environment variable, or a third-party script whose domain has been retired.

For Site Owners: When Everyone Sees It

If visitors across different networks report ERR_NAME_NOT_RESOLVED, your domain's DNS is the problem. Check from outside your network:

dig www.example.com A +short @1.1.1.1
dig www.example.com A +short @8.8.8.8
dig example.com NS +short @1.1.1.1

If the name doesn't resolve on public resolvers, check that the domain hasn't expired, that its nameservers at the registrar point to your DNS host, and that a record exists for the exact hostname visitors are using. Remember that example.com and www.example.com are separate names and each needs its own record.

---

FAQ: ERR_NAME_NOT_RESOLVED

---

Conclusion

ERR_NAME_NOT_RESOLVED means Chrome couldn't get an IP address for a hostname. Because Chrome keeps its own cache and can use its own Secure DNS provider, the fix is often inside the browser: clear the host cache, check Secure DNS, and rule out extensions. If other apps fail too, flush the system cache, check the hosts file and switch DNS servers.

When the usual fixes don't work, chrome://net-internals/#dns and chrome://net-export show you exactly what Chrome's resolver is doing. Developers should also keep router rebinding protection and broken subresource hostnames in mind. And if everyone sees the error, look at the domain's registration, nameservers and records, because the browser is only reporting what DNS told it.