Diagnose DNS failure on Windows 11 with nslookup, not guesswork

A browser message saying a site cannot be reached may be caused by DNS, but it can also be a proxy, certificate, firewall or site outage. `nslookup` asks a DNS server directly and reports the server used, so it helps distinguish name resolution from a general connection problem. A single successful lookup is not proof that the browser path works; it is one branch of the investigation.

Before you start​

Choose a legitimate domain you know should resolve and record the original failing domain. Note your configured DNS server and whether a VPN, work profile or DNS-over-HTTPS browser setting is active. Avoid switching to a public DNS server on a managed device without approval because internal names and filtering may depend on corporate DNS.

Do it step by step​

1. Confirm the adapter has an address and default gateway with `ipconfig /all`. If it has a 169.254.x.x address or no gateway, fix network assignment first; DNS is downstream.
2. Run `nslookup example.com` and then the failing legitimate domain. Record the Server line, returned addresses or error and timestamp. A result for one name but not the other suggests a domain-specific or policy problem.
3. Compare the same lookup from a second device on the same network and, if safe, from the PC on a phone hotspot. If the failure follows the router, inspect its DNS configuration or provider rather than changing Windows files.
4. If the configured resolver is failing only on this PC, run `ipconfig /flushdns` once and retry. Microsoft's ipconfig documentation confirms this clears the local resolver cache; it does not repair an unreachable external DNS server.
5. Inspect VPN and proxy state and the browser's own secure-DNS setting. Browser DNS-over-HTTPS may produce a different result from a plain nslookup query; note that distinction rather than calling either result wrong.
6. Restore any temporary test settings, then verify the target site in the actual browser or app. Document whether the fix was local cache, resolver configuration, VPN or a remote outage.

Check the result​

Both command-line lookup and the intended app resolve and reach the target after the change. The DNS server used is one you actually intended to trust.

If something goes wrong​

A DNS answer can exist while HTTPS is blocked by another layer. If only one domain fails on multiple networks, check its service status. If internal work names fail only off VPN, reconnect through the official work route instead of hardcoding public DNS.

Know the limit​

nslookup diagnoses DNS infrastructure; it does not validate the website's identity or safety. Flushing cache is reversible but not a universal internet fix. Avoid editing the hosts file without a documented reason and rollback copy. Microsoft nslookup Microsoft ipconfig

Decision checkpoint​

When comparing DNS servers, change only one test condition. A public resolver can answer ordinary internet names but not a company's private namespace, so an apparent improvement may break work applications. Save the original configuration and restore it after the comparison. Name resolution and certificate validation are separate checks.