When a website fails to load, check whether your computer can resolve its name before changing router settings. On Windows, run nslookup for the failing domain and for a known working domain. Compare the results with a second device. These checks can distinguish a name lookup problem from a website outage, a browser issue, or a broader connection failure.
Find out which devices and sites are affected
Write down the exact hostname and error. A page that opens at one address but fails at a different subdomain can point to a specific record. Try another website and, if possible, another browser. Record whether the problem affects only one service or many unrelated ones. If the browser shows a certificate warning, do not proceed through it. That warning needs its own investigation and does not establish that DNS failed.
Compare with a second device on the same network. If both devices fail on Wi-Fi, try the same site on the phone using mobile data. A result that changes when you switch networks gives you a useful comparison, although the two networks also use different paths and may use different resolvers. If the mobile network cannot open the site either, check the service’s status before assuming your home router needs changes.
Check whether your computer is actually online. If several applications are failing and the network icon shows a disconnected state, restore the connection first. Our Wi-Fi dead zone guide covers local signal problems. If Ethernet is connected but has fallen to an unexpected rate, see our Ethernet link-speed guide. A physical or wireless link fault can affect DNS along with everything else.
Compare a failing and working lookup
Open Command Prompt and run nslookup example.com as a baseline. Then replace example.com with the exact hostname you cannot open. Use the hostname alone, without a URL path. The output normally identifies the resolver and reports an answer or error. See Microsoft’s nslookup reference for how to specify a server and read the command output.
If the failing hostname returns an address, check whether the browser still shows a name-resolution error. A browser can use its own secure DNS configuration or a cached answer. An application might also use a VPN or proxy. Write down which application fails and what the command returns. These results describe different parts of the connection, so one successful lookup does not prove that the website itself is reachable.
If the lookup times out, repeat once with the working hostname. A timeout on both names can indicate that the current resolver is unreachable or failing to respond. If one name returns an answer and the other is reported as nonexistent, check the spelling and the service’s official address. A valid response indicating no such name is different from a resolver that never responds. Keep the exact message for your notes.
Compare resolvers without changing the whole network
If you have a known alternate resolver you are allowed to query, specify it as the second argument to nslookup. Compare the same hostname with the default resolver and the alternate. This tests one query without changing the router or every device on the network. Use a public hostname for this comparison. Private names used by work networks or local devices may only resolve through the intended private resolver.
If results differ, record both and repeat after confirming the correct hostname. Results can legitimately differ because some services direct users to different servers or because a record changed recently. An address difference alone is not a fault. Look for the difference that matches the symptom, such as repeated timeouts on the default resolver and consistent answers from another connection. On a managed network, bring the results to the administrator before changing settings.
If a VPN is involved, compare with and without it only if your organization allows that. Some applications require the VPN to reach a private name or service. If the failing name works only with the VPN, that may be intentional. Conversely, if ordinary sites fail only while the VPN is active, check the VPN provider’s support guidance and report both test results rather than altering company DNS settings.
Apply the narrow fix and retest
If only one browser is affected, check its network and secure DNS settings and try a fresh session using the browser’s documented troubleshooting steps. If every device behind one router is affected, confirm whether the router provides the resolver address and whether the upstream service reports an outage. Save any existing settings before making an authorized change. Then retest from the same computer and from a second device.
After any change, repeat the failing and working lookup and open the original page. If the lookup succeeds while the page still fails, keep troubleshooting the service or connection instead of changing the resolver again. If the issue happens only when the household uploads large files, our latency and packet loss guide explains how to compare quiet and busy periods.
Record the resolver used, the time, the exact domain and the result. For an intermittent problem, include whether the second device was affected at the same time. A useful support note says which lookups timed out, which network worked, and what changed when you compared them. Avoid posting private hostnames or internal network details in a public forum.
Suppose a work laptop can open ordinary websites, but an internal project site fails. The same name returns no answer on your phone using mobile data, and the laptop only reaches it when the work VPN is connected. That is consistent with a private service using the organization’s resolver. Instead of changing the home router, confirm the VPN is connected and ask the administrator if the hostname or access requirements changed. For a public site, the comparison looks different. If several unrelated public names time out on all devices behind the home router while mobile data works, capture that pattern and check the router or provider. If just one public name returns an error across independent networks, focus on the hostname or service first. Keep a short timeline so a temporary outage does not get mistaken for a lasting fix. Include the first failure, the test from the second network, and when the page became reachable again. If you retest after an authorized settings change, repeat the original lookup before opening a different page. That keeps the result tied to the reported problem.
Frequently asked questions
Does a DNS error mean my internet is down?
No. Compare other sites and devices, then test a lookup. Some failures affect a single name or application.
Does changing DNS fix slow downloads?
A resolver helps find addresses. It does not directly increase the capacity of an ongoing transfer.
Why does the site work on my phone using mobile data?
The phone uses a different network and may use a different resolver. Compare additional tests before assigning the cause.
Can I test another resolver without changing my router?
Yes. Nslookup accepts a server argument. Query a public hostname and keep the original settings in place during the comparison.
