net::ERR_NAME_NOT_RESOLVED

The exact error string

GET https://api.exmaple.com/users   net::ERR_NAME_NOT_RESOLVED

// In fetch, it surfaces as a generic network failure:
fetch('https://api.exmaple.com/users')
// Uncaught (in promise) TypeError: Failed to fetch
// Console / Network tab shows: net::ERR_NAME_NOT_RESOLVED

// Full-page Chrome version of the same DNS result:
//   This site can't be reached
//   DNS_PROBE_FINISHED_NXDOMAIN

Note that in JavaScript a fetch to an unresolvable host rejects with the generic TypeError: Failed to fetch — the ERR_NAME_NOT_RESOLVED detail appears in the console and the Network tab. That detail is the clue that the cause is DNS, not CORS or the server.

What "name not resolved" actually means

Before a browser can send a request it must convert the hostname (api.example.com) into an IP address (93.184.216.34) via DNS. ERR_NAME_NOT_RESOLVED means that lookup returned nothing — there is no address to connect to, so the request is abandoned at the very first step.

This places it earlier in the request lifecycle than most network errors. Compare:

Triage first: one host, or all hosts?

This single question splits the problem in half. Open a couple of unrelated websites:

• Other sites load, this one doesn't → the problem is this hostname: a typo, an expired/nonexistent domain, a missing DNS record, or a local-only host. Go to Cause 1–2.
• Nothing loads → the problem is your DNS or connection: a bad resolver, a VPN/proxy, or an offline network. Go to Cause 3–4.

Cause 1: a typo or missing protocol

By far the most common cause. Check the hostname character by character, and make sure the URL has a scheme — a bare host or a stray space breaks resolution:

fetch('https://api.exmaple.com')   // ❌ "exmaple" — transposed letters
fetch('htps://api.example.com')    // ❌ malformed scheme
fetch('api.example.com')           // ❌ no protocol — treated as a relative path/host
fetch('https://api.example.com')   // ✅

// Built from an env var? Log it — a missing variable yields "https://undefined"
console.log(import.meta.env.VITE_API_URL);  // undefined → unresolvable host

A frequent programmatic version: building the URL from an environment variable that is empty, producing https://undefined/... or https:///path. If the host looks wrong, see process.env.X is undefined.

Cause 2: a local hostname with no mapping

Made-up development hostnames like myapp.local, api.dev, or backend only resolve if something maps them to an IP. Without a hosts entry, a local DNS server, or container DNS, the browser cannot resolve them:

# Use a real loopback address instead of a made-up name:
http://127.0.0.1:3000        # ✅ always resolves
http://localhost:3000        # ✅ resolves on every OS

# Or map the custom name in your hosts file:
#   Windows: C:\Windows\System32\drivers\etc\hosts
#   macOS / Linux: /etc/hosts
127.0.0.1   myapp.local      # now myapp.local resolves to localhost

Inside Docker or Kubernetes, service names resolve only on the internal network — a service called api is reachable from another container, but not from your browser on the host. From the browser, use the published localhost:PORT mapping.

Cause 3: DNS cache, resolver, or VPN

If every site fails, suspect the resolver. Flush the DNS cache, switch to a public resolver, and rule out a VPN or proxy:

# Flush DNS cache
ipconfig /flushdns                       # Windows
sudo dscacheutil -flushcache             # macOS
sudo resolvectl flush-caches             # Linux (systemd)

# Test resolution directly (bypasses the browser):
nslookup api.example.com
nslookup api.example.com 1.1.1.1         # force a public resolver

# Then set the OS/router DNS to a public one:
#   Cloudflare 1.1.1.1   or   Google 8.8.8.8

A VPN, corporate proxy, or ad-blocking DNS can also blackhole specific names — disable it briefly to test. Chrome's own DNS cache can be cleared at chrome://net-internals/#dns.

Cause 4: the domain genuinely doesn't exist

If nslookup also fails from a known-good resolver, the name truly has no DNS record — an expired domain, a record that was never created, or a propagation delay on a brand-new domain (new DNS records can take minutes to ~48 hours to propagate). Here the fix is on the domain/DNS side, not your machine.

The Node.js equivalent: getaddrinfo ENOTFOUND

The same DNS failure on the server side — in Node, Deno, or any backend making an outbound request — surfaces as ENOTFOUND, not ERR_NAME_NOT_RESOLVED. It means exactly the same thing: the hostname could not be resolved to an IP:

Error: getaddrinfo ENOTFOUND api.example.com
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:...)
  errno: -3008,
  code: 'ENOTFOUND',
  syscall: 'getaddrinfo',
  hostname: 'api.example.com'

The causes and fixes are identical to the browser case: a typo or empty env var building the host, a local-only hostname with no mapping (very common when one container calls another by a name that only resolves inside the Docker/K8s network), or a broken resolver. The hostname field in the error tells you exactly what failed to resolve — log the URL you built before the request to catch an undefined host early. A closely related sibling is ECONNREFUSED, which (like its browser twin) means DNS succeeded but the connection was refused.

Confirm it from the command line

Take the browser out of the picture to prove whether it is DNS or something higher up. If these fail too, it is genuinely DNS; if they succeed but the browser fails, suspect a browser/VPN/proxy layer:

nslookup api.example.com            # does the name resolve at all?
nslookup api.example.com 1.1.1.1   # does it resolve via a public DNS?
ping api.example.com               # resolves + reaches? (DNS shows the IP)
curl -v https://api.example.com    # curl prints "Could not resolve host" on DNS failure

Debugging checklist

• ✓ Re-read the hostname for typos; confirm the URL has https://
• ✓ Building the URL from an env var? Log it — watch for undefined in the host
• ✓ Do other sites load? Yes → host-specific; No → your DNS/network
• ✓ Local hostname? Use 127.0.0.1/localhost or add a hosts entry
• ✓ Flush DNS; test with nslookup against 1.1.1.1
• ✓ Disable VPN/proxy/ad-block DNS to rule it out
• ✓ nslookup fails everywhere? The domain has no record — fix it at the registrar/DNS
• ✓ Server side (Node/Deno)? Same DNS failure shows as getaddrinfo ENOTFOUND — check the hostname field