Chrome ERR_NAME_NOT_RESOLVED: Find the Actual DNS Failure

This guide distinguishes ERR_NAME_NOT_RESOLVED from similar browser failures before changing the computer, network or website. Name resolution fails before a usable destination address is available. It is different from a server refusing a TCP connection. A nonexistent hostname, missing DNS record or policy-specific resolver can all lead here.

Symptoms: recognize this failure

A browser error is an observation, not a complete root-cause diagnosis. First identify whether the problem follows the website, your device, a particular network, or the logged-in session.

• Chrome immediately says the site cannot be reached and shows ERR_NAME_NOT_RESOLVED.
• The site works by IP address in a controlled test but not by its hostname.
• An internal business hostname works only when connected to the organization VPN.

Capture the exact URL, the complete error code, local time with time zone and the operation in progress. If the issue occurs only after sign-in, keep credentials, cookies and session identifiers out of screenshots or logs.

Why ERR_NAME_NOT_RESOLVED occurs

The same message may appear after different failure paths. These are plausible causes, not confirmation that any one component is defective:

• The domain was mistyped, expired or never had a valid DNS record.
• DNS resolvers are unavailable or return a stale negative result.
• Local hosts entries, DNS filtering or split-DNS rules change the answer.
• The VPN or network-specific DNS server required for an internal hostname is absent.

Evidence that separates the causes

Compare those observations with both a known-good destination and the exact failing operation. The result of a single test is rarely enough: a successful DNS lookup does not prove that TLS works, and a successful TCP handshake does not guarantee that the application responds correctly.

Before making any changes

Preserve evidence before attempting repairs. Save the original page address and error text, and note whether the failure began after an update, DNS change, browser extension, VPN change or website deployment. On managed networks, respect administrator policy.

If the failing request might submit a payment, order, password change or upload, verify its server-side result before retrying. An error page does not prove that the intended operation did not complete.

Diagnosis: interpret the result before repairing

Distinction one: where the failure occurs

NXDOMAIN indicates a reported lack of a matching name, while timeouts or SERVFAIL indicate a different class of resolver failure. Preserve the exact answer rather than treating them as equivalent.

Distinction two: what the evidence means

A browser can use Secure DNS while the operating system uses another resolver. Compare the two paths when the results disagree.

When the evidence is inconclusive, record that uncertainty rather than applying unrelated fixes. A targeted comparison between the affected connection and an authorized alternate path is more useful than clearing every cache or reinstalling the browser.

Common mistakes to avoid

• Do not confuse DNS NXDOMAIN with a certificate or HTTP 404 problem.
• Do not edit the hosts file as a permanent substitute for broken authoritative DNS.
• Do not disable DNS filtering or corporate policy to force a lookup.

Avoid changing several variables at once. Otherwise, a lucky successful reload cannot establish whether a particular action fixed the original failure.

How to verify the repair

Recreate the original failure condition as closely as practical. Test the same hostname, route and network first, then check one unrelated page to ensure normal browsing was not accidentally affected. For transient issues, repeat the test and observe long enough to distinguish a real improvement from a short-lived recovery.

• The hostname resolves consistently using the expected resolver on the affected network.
• The intended HTTPS page loads without silently falling back to an unrelated destination.

Use the checklist below to record these checks. Its completion indicator tracks reading progress, not an automated test of system health.

If the error continues: rollback and escalation

Undo only the change made during this investigation, restore any previously recorded settings and retry the exact problem once. If the issue persists, send a support contact the error code, affected URL, time including time zone, affected browser/version, results on alternate networks and sanitized diagnostic observations. Never attach passwords, private tokens, raw session cookies, private-key files or personal data.

For a site you administer, correlate browser observations with the relevant application, reverse-proxy, TLS or DNS logs. For a site you do not control, avoid invasive scans and contact the operator through an official support route.

Prevent the error from returning

• Monitor domain renewals and authoritative DNS record changes.
• Document internal DNS dependencies and split-DNS requirements for VPN users.

Maintain a short incident record: symptom, evidence, confirmed cause (if identified), single change, verification and rollback. That history is more reliable than a list of unverified “fixes.”

Further reading: official technical references

• Google Chrome Help — common error messages
• Chromium — network error definitions

Documentation and browser menus can change by version. Confirm current steps against the official product documentation. These scenarios describe possible causes, not a guaranteed diagnosis.