Did the name fail, or did something answer?
A website that will not open can have a broken name lookup, an unreachable connection, or a working front door with a broken application behind it. The useful distinction is where the request stopped. Changing DNS cannot repair every one of those failures.
This guide uses Windows 11 and Chrome desktop on a personally controlled computer. Its main test compares DNS answers without changing your network configuration. It is for a public website; keep internal company names on their required network and VPN, and leave managed settings to the administrator.
Copy the exact browser error and hostname before retrying. The hostname is the part such as www.example.com, without https:// or the page path. Check spelling and whether a redirect changed the name. A working homepage does not clear a failing checkout or login hostname.
- A message saying the server address could not be found makes DNS worth checking.
- A fresh HTTP 502 or 503 error page means an HTTP service or intermediary answered. It points beyond a simple failure to find the initial hostname.
- A connection timeout leaves the cause open. DNS might have worked before a route, firewall, or server stopped the connection.
Cloudflare’s 5xx guidance distinguishes errors across its edge and the origin server. Even a recognizable error page does not prove the underlying application is reachable. Preserve certificate warnings rather than clicking through them.
Establish two controls before touching settings
Request a fresh page from two unrelated, familiar sites in the same Chrome window. Record whether they load now. Previously open tabs can display old content even during an outage. If everything fails, check whether the computer actually has internet access before blaming one website.
Next, try the affected address on an owned phone with Wi-Fi switched off and mobile data enabled, if your plan allows it. Restore Wi-Fi afterward. Success on mobile data shows an alternative route works; it does not isolate DNS, because the device, resolver, and network route all changed.
If the site fails across those connections while unrelated sites load, look for the service’s official status page using a known address or official support link. A posted incident is useful corroboration. No posted incident is weaker evidence: the problem may be new, regional, or limited to one feature.
Ask the same public-name question twice
Press Windows + R, type cmd, and press Enter. This opens an ordinary command window; the lookup needs no administrator elevation. Run these commands separately, replacing www.example.com. with the affected public hostname and retaining the final period:
nslookup www.example.com.
nslookup www.example.com. 1.1.1.1The first uses the default resolver; the second asks the specified resolver for that command only. The final period avoids search-suffix ambiguity. Microsoft documents both forms in its nslookup reference. There is no network setting to undo. The second query shares that public hostname with Cloudflare’s public resolver; skip it if network policy disallows external DNS.
Save both results with the time. Read the answer for the requested hostname below the resolver information, rather than mistaking the resolver’s own address for the website’s address. A returned address establishes an answer, not that the answer is correct or the destination works. Different address lists alone are not proof of trouble: distributed sites can return different destinations.
If the results conflict, repeat the pair once with a familiar public hostname that currently opens in Chrome. This control helps distinguish failure for one name from broad resolver trouble. Do not substitute an internal work name or run an endless query loop.
| Observed result | Next interpretation |
|---|---|
| Default fails; alternate answers | A discrepancy in resolver answers or their network paths. Stronger evidence if a second public name behaves similarly. |
| Both answer; browser still fails | Check the browser’s resolver path and the later connection. An address answer cannot certify website health. |
| Both fail for this name; control answers | Investigate this domain’s DNS or policy treatment. Do not declare a worldwide website outage. |
| Both time out for multiple names | Check connectivity or DNS filtering. External DNS may simply be blocked on this network. |
A timeout means no timely reply; a nonexistent-domain reply reports that the name does not exist in that DNS view. Server failure is a different error again. Keep the exact wording, and first recheck spelling. None of these responses alone identifies the responsible organization.
When Chrome disagrees with the command window
Open Chrome’s More → Settings → Privacy and security → Security. Under Advanced, inspect Use secure DNS and record whether a custom provider is selected. Google’s desktop security instructions verify this path. A Chrome lookup can follow a different route from your command-line query.
Google says automatic mode can fall back to unencrypted lookup when necessary; a selected custom provider does not automatically make that fallback. If a personal Chrome installation uses a custom provider and only Chrome fails, record the original toggle and provider. Temporarily turn Use secure DNS off, retry the affected address once, then restore the original setting and retry again.
If the failure disappears only during that comparison, investigate the custom provider or its reachability. This is evidence about that path, not proof of a global DNS outage. Turning the feature off changes lookup privacy, so leave it off only as a deliberate later decision. If management or parental controls restrict the feature, skip the change.
Choose recovery that matches the evidence
If DNS answers now succeed but this Windows computer still appears stuck on an earlier failed lookup, one bounded repair is clearing its DNS client cache. Save the earlier results first. Open Start, search for Command Prompt, choose Run as administrator, and approve only on a computer you administer. Then run:
ipconfig /flushdnsMicrosoft’s ipconfig documentation explains that this resets the local resolver cache, including negative entries. Wait for the command’s success confirmation, then retry the original address. If permission is denied, stop rather than changing security policy.
This removes cached lookup data; it does not erase cookies or change the DNS server. There is no cache restoration step: later lookups populate it again. It cannot clear an upstream resolver’s cache, guarantee Chrome discards its own state, or repair a domain’s authoritative records. Avoid unrelated release, reset, and router factory-reset commands.
If fresh error pages continue across networks, use the site’s official support channel. If multiple public names fail only through the default resolver, give the network provider the paired results. If only Chrome’s custom-provider path fails, include the before-and-after comparison. Keep full URLs containing account tokens out of reports.
For example, a hypothetical report might say: “At 09:15 local time, both resolvers returned addresses, but this hostname produced a fresh 503 on home Wi-Fi and mobile data; two unrelated sites loaded.” That supports service-side investigation without claiming the origin server is down. Replace those invented observations with your own, and append the time recovery occurs. Stop changing settings once you have a coherent result.
Sources, versions & scope
The steps describe the documented controls and expected checks; they are not a claim that every device or software release has been physically tested. Platform and version differences are stated with the procedure.
