ERR_NAME_NOT_RESOLVED

The short version: It means Chrome's DNS lookup for the hostname failed, so the browser has no IP address to connect to. The most common fix is to flush your DNS cache and switch to a reliable public resolver such as 1.1.1.1 or 8.8.8.8.

Key takeaways

• ERR_NAME_NOT_RESOLVED is Chromium net error -105: the DNS lookup for the hostname returned no IP, so the browser never opens a connection. The server's health is irrelevant because no request ever leaves your machine.
• It is broader and more often transient than DNS_PROBE_FINISHED_NXDOMAIN: a stale cache entry, a flaky resolver, or a blocked Secure DNS endpoint can trigger it even when the domain is fine.
• The fastest fix for visitors is to flush the DNS cache and switch to a reliable resolver such as 1.1.1.1 or 8.8.8.8; if a refresh alone clears it, suspect your local cache.
• To tell whose fault it is, run dig yourdomain.com @1.1.1.1: an IP means DNS works and the issue is your browser or resolver, while no answer points at the domain's records.
• Prevention for owners is redundant DNS, domain auto-renew, and external monitoring that resolves the hostname from outside so a silent resolution failure pages you, not your visitors.

Error type

Browser DNS resolution error (Chromium net error -105)

Whose side

Either

Fix difficulty

Easy

Common cause

DNS lookup of the hostname failed: bad cache, wrong resolver, or a missing or misspelled domain

What does ERR_NAME_NOT_RESOLVED mean?

Every time you open a website by name, the browser has to find the matching IP address through DNS. Your device asks a resolver (usually your ISP's, your router's, or a public one like Cloudflare or Google), which walks the DNS hierarchy until it returns an address. ERR_NAME_NOT_RESOLVED is Chrome's way of saying that this entire lookup came back empty: the browser literally has no IP to dial, so it never opens a TCP connection. In Chromium's net error list the code is -105, defined simply as 'the host name could not be resolved.'

A genuinely useful distinction that most guides skip: ERR_NAME_NOT_RESOLVED is the generic 'name resolution failed' result, while DNS_PROBE_FINISHED_NXDOMAIN is what Chrome shows after it runs its own diagnostic DNS probe and gets back an authoritative NXDOMAIN, meaning the domain provably does not exist. ERR_NAME_NOT_RESOLVED is broader and is often transient (a stale cache entry, a momentarily unreachable resolver, a flaky Wi-Fi handoff), whereas NXDOMAIN is more likely to mean the name is misspelled or the domain truly has no records. If you only ever see ERR_NAME_NOT_RESOLVED and a refresh fixes it, suspect your local resolver or cache, not the domain.

A modern and frequently missed cause is Chrome's Secure DNS (DNS over HTTPS). When you set a custom DoH provider under Settings, Chrome routes lookups to that encrypted endpoint instead of your normal resolver. If that endpoint is blocked on your network, temporarily down, or cannot see internal or split-horizon domains, names that would otherwise resolve start failing with ERR_NAME_NOT_RESOLVED. Switching Secure DNS back to your provider's default, or turning it off to test, is a fast way to rule this in or out.

Because the failure happens before any HTTP request leaves your machine, the web server's own health is irrelevant to this error. A perfectly running server still shows ERR_NAME_NOT_RESOLVED if its DNS record is missing, if your resolver is misbehaving, or if a typo sent you to a hostname that was never registered.

-105

Chromium net error code behind the message

2

DNS lookups per request: one for IPv4 (A), one for IPv6 (AAAA)

Up to 48h

DNS propagation window after a new or changed domain record

How the ERR_NAME_NOT_RESOLVED error appears

The wording changes depending on your browser, device, or server. Here is how this error commonly shows up:

example.com

This site can't be reached

example.com's server IP address could not be found.

ERR_NAME_NOT_RESOLVED

• ERR_NAME_NOT_RESOLVED The exact Chromium code (-105): the host name could not be resolved to an IP
• This site can't be reached Chrome's headline shown above the error code
• example.com's server IP address could not be found The plain-language sub-line Chrome prints for a failed DNS lookup
• Error 105 (net::ERR_NAME_NOT_RESOLVED) The older numeric form of the same error in legacy Chrome builds
• net::ERR_NAME_NOT_RESOLVED The fully namespaced form often seen in DevTools and page-load logs

ERR_NAME_NOT_RESOLVED vs related DNS and connection errors

These Chrome errors look similar but point at different stages of resolving and connecting to a website. Knowing which one you have narrows the fix.

Commands to pinpoint a name-resolution failure

Each command tests a different part of the lookup path so you can tell a local cache problem from a true DNS failure.

Where name resolution can break

ERR_NAME_NOT_RESOLVED can originate at any link in the chain; this maps each layer to who can fix it.

What causes ERR_NAME_NOT_RESOLVED?

• A stale or corrupted DNS cache on your device, browser, or router returning a dead or empty answer
• An unreliable or unreachable DNS resolver (often the ISP default), or a custom Secure DNS / DoH endpoint that is blocked or down
• A misspelled hostname, or a domain that has expired or never had DNS records created
• DNS records that have not finished propagating after a new domain, a host migration, or a nameserver change
• A hosts file entry or VPN, proxy, firewall, or security tool that intercepts or breaks name resolution
• Domain-side problems such as broken nameservers or a DNSSEC misconfiguration that makes the lookup fail validation

How to find the cause fast

1. Try the same address on another network (for example a phone on mobile data). If it loads there, the problem is local to your first network or device, not the website.
2. Run a direct DNS query to see what the world's resolvers return, for example 'nslookup example.com' or 'dig example.com'. An answer with an IP means DNS is fine and the issue is your browser or cache; NXDOMAIN or 'server can't find' means the name does not resolve.
3. Query a known-good public resolver explicitly with 'nslookup example.com 1.1.1.1' or 'dig @8.8.8.8 example.com'. If that succeeds while your default resolver fails, your configured DNS server is the culprit.
4. Test raw reachability with 'ping example.com'. If ping cannot resolve the host either, the failure is system-wide DNS, not Chrome.
5. In Chrome, visit chrome://net-internals/#dns and clear the host cache, then retry; this isolates a stale in-browser cache entry from a true DNS failure.

Terminal

nslookup example.com** server can't find example.com: NXDOMAIN# DNS returned no IP, so Chrome shows ERR_NAME_NOT_RESOLVED

How ERR_NAME_NOT_RESOLVED looks from the outside

From the outside, a DNS failure is invisible to ordinary HTTP status checks because the request never gets far enough to return a status code: the lookup itself fails first. Pulsetic catches this because every check it runs starts with DNS resolution from 15+ global locations, on intervals as fast as 30 seconds. If the hostname stops resolving, the check fails and Pulsetic alerts you by email, SMS, voice, Slack, Discord, Telegram, or webhook. Its dedicated domain check also watches the registration and expiry of the domain itself, so an expired or misconfigured name is flagged directly. Because Pulsetic tests from outside your network, it sees the same resolution path your visitors do, not just your own machine's possibly cached view.

How to fix ERR_NAME_NOT_RESOLVED

For visitors

1. Double-check the spelling of the address in the URL bar, including the domain ending.
2. Reload the page, then restart Chrome; transient lookups often clear on a second try.
3. Flush your DNS cache (see the platform steps below) so the browser asks fresh.
4. Switch your device or router to a reliable public DNS resolver such as Cloudflare (1.1.1.1 and 1.0.0.1) or Google (8.8.8.8 and 8.8.4.4).
5. Turn off or change Chrome's Secure DNS: Settings > Privacy and security > Security > Use Secure DNS, then set it to your provider or disable it to test.
6. Restart your router and, if you use a VPN or proxy, disconnect it and retry.

For website owners

1. Confirm the domain is registered, not expired, and that its nameservers are correct at the registrar.
2. Verify A and AAAA records exist and point to the right IP using 'dig A example.com' and 'dig AAAA example.com' against an external resolver.
3. If you just changed DNS or migrated hosts, allow for propagation and check from multiple public resolvers, not only your own machine.
4. If DNSSEC is enabled, validate the chain (for example 'dig +dnssec example.com') and fix any broken or mismatched DS or RRSIG records.
5. Make sure both the apex (example.com) and www, plus any subdomains you advertise, all resolve.
6. Set up external DNS and uptime monitoring so a future resolution failure pages you before visitors notice.

Windows

1. Open Command Prompt as Administrator.
2. Run 'ipconfig /flushdns' to clear the resolver cache.
3. If names still fail, run 'netsh winsock reset' and restart the PC.
4. Optionally set DNS manually under Settings > Network & Internet > your adapter > DNS server assignment.

macOS

1. Open Terminal.
2. Run 'sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder' and enter your password.
3. Change DNS if needed under System Settings > Network > your connection > Details > DNS.
4. Quit Chrome fully (Cmd+Q) and reopen it so it picks up the fresh resolver.

Chrome

1. Visit chrome://net-internals/#dns and click 'Clear host cache'.
2. Visit chrome://net-internals/#sockets and click 'Flush socket pools'.
3. Go to Settings > Privacy and security > Security > Use Secure DNS and switch provider or toggle it off to test.
4. Disable Chrome's preload setting under Settings > Privacy and security > Cookies and other website data > Preload pages, then retry.

Still not fixed? Next steps

• If dig @1.1.1.1 and dig @8.8.8.8 both succeed but your machine still fails, run netsh winsock reset on Windows or restart systemd-resolved on Linux, since the OS resolver stack itself may be corrupted.
• If only some subdomains fail, query each one explicitly (dig www.yourdomain.com, dig api.yourdomain.com): a missing record on one host while the apex resolves narrows the fix to that single DNS entry.
• If public resolvers disagree with your authoritative server, the change has not propagated yet; check the record's TTL and confirm you edited the live zone at the provider listed in dig NS yourdomain.com.
• If resolution fails only with DNSSEC validation on, temporarily test with dig +cd (checking disabled) to confirm the chain is the cause, then correct or roll back the DS and RRSIG records at the registrar and DNS host.

Code & configuration

Copy-paste starting points. Replace example.com and the paths with your own, and test changes on staging before production.

Check what DNS actually returns

nslookup example.com
dig example.com +short
dig @1.1.1.1 example.com

Flush the DNS cache

# Windows (Admin Command Prompt)
ipconfig /flushdns

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

# Linux (systemd-resolved)
sudo resolvectl flush-caches

Confirm A and AAAA records as a website owner

dig A example.com @8.8.8.8
dig AAAA example.com @8.8.8.8
dig +dnssec example.com

How to prevent ERR_NAME_NOT_RESOLVED

Most repeat occurrences come from fragile DNS: a single ISP resolver, a soon-to-expire domain, or records that quietly break after a migration. Use a reputable, redundant DNS provider, keep domain auto-renew on, and verify records from multiple external resolvers after any change. To catch the failures you cannot see from your own desk, point Pulsetic at your domain: its uptime and domain monitoring resolve your hostname from 15+ locations every 30 seconds and alert you the moment resolution breaks, turning a silent DNS outage into an instant notification instead of a wave of visitor complaints.

Learn how Pulsetic's domain monitoring detects this from the outside, across 15+ locations.