ERR_NAME_NOT_RESOLVED

When Chrome shows ERR_NAME_NOT_RESOLVED, it means the browser asked the operating system to turn a hostname into an IP address and the lookup failed. Unlike a specific negative answer, this is a general failure of name resolution: no record came back at all. The browser had nowhere to send the request, so the page never left your machine. The site may well be running — the browser simply could not find its address.

What it means

Name resolution is the step that maps a readable hostname to a numeric address. The browser hands the name to the system resolver, which checks its local cache, then the hosts file, and finally queries a DNS server. If that whole path fails — the resolver is misconfigured, no server answers, or the reply carries no usable record — the browser reports that the name was not resolved.

This error is a broader bucket than a formal NXDOMAIN. A domain that truly does not exist can produce it, but so can a dropped packet to the DNS server, a disabled network adapter, a VPN split-tunnel that routes DNS nowhere, or a security suite blocking port 53. That breadth is why the first job is to find out whether any resolution works or only this one name fails.

Two quick tests separate the cases. Try a well-known site: if everything fails, your resolver or connection is the problem. If only one site fails, focus on that hostname and your cache. If every name fails only inside the browser while other apps work, a browser setting or extension is involved. Recording which of these you see narrows the cause immediately.

It also helps to know the difference between this error and a slow one. A name that resolves slowly still produces a connection; a name that does not resolve produces nothing at all, so no request ever reaches the destination. That distinction tells you to look at DNS rather than at the web server, the certificate, or the application, and it keeps you from wasting time restarting services that were never the problem.

Common causes

• A typo in the address, or a bookmark that points at a hostname that no longer exists.
• No network connectivity, a down adapter, or a Wi-Fi captive portal that has not been acknowledged.
• Misconfigured or unreachable DNS servers, or a VPN that redirects DNS traffic.
• A corrupt local DNS cache, or a hosts-file line that maps the name incorrectly.
• Security software, a proxy, or a browser extension interfering with DNS queries.

How to fix it

1. Prove the scope. Load a well-known site. If it also fails, treat it as a general connectivity or DNS problem; if only one site fails, move on to that name.
2. Test the lookup directly. Query a public resolver to see whether the record exists at all.

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

3. Flush the resolver cache and renew the connection. On Windows:

   ipconfig /flushdns
   ipconfig /release
   ipconfig /renew

4. Check the hosts file. Open C:\Windows\System32\drivers\etc\hosts (or /etc/hosts) as administrator and remove entries for the failing name, then flush again.
5. Set a reliable DNS server and rule out blockers. Point the adapter at resolvers such as 1.1.1.1 and 8.8.8.8, disconnect any VPN, and pause security software or extensions that touch the network. Retest in a clean browser profile.

How to prevent it

Keep a small routine that makes DNS failures easy to read. Note the resolver you rely on, and keep a public fallback ready so you can tell in seconds whether a failure is local or on the domain's side. Learn one lookup command and use it before you start changing settings. Bookmark the sites you use daily rather than retyping hostnames, and clean out bookmarks that point at hosts long since retired.

Keep your network drivers and router firmware current, and prefer automatic DNS from a provider you trust over hand-typed addresses you might later forget. If you use a VPN or filtering resolver, document how it handles DNS so you recognize its failures as intentional rather than mysterious. And when a site you do not control stops resolving, check an independent resolver before assuming the fault is yours — sometimes the answer is simply that the domain is gone.