Is the site actually down?
Before you blame your wifi, find out whether the site is broken for everyone or just for you. Two free third-party services answer this in one click: downforeveryoneorjustme.com and isitdownrightnow.com. Paste the hostname, and they'll attempt a fetch from their own servers and report back.
If both report the site is down globally, you're done troubleshooting on your end — the operator has work to do, not you. Check the company's status page or their social accounts; outages are usually acknowledged there first. If those services report the site is up but you still can't reach it, the problem is somewhere between your device and their server, and the rest of this guide is for you.
Test from another network
The single fastest way to localize a connectivity problem is to try the same site from a completely different network path. Turn wifi off on your phone, switch to mobile data, and load the page. If it works on cellular, the problem is your home or office network — not the site and not the wider internet. If it fails on cellular too, the issue is further upstream.
You can also tether your laptop to your phone, or ask a friend on a different ISP to try. Every additional network you test from removes another variable. If the site loads from three different networks but not yours, you've conclusively proven the problem lives on your side.
Is DNS resolving the domain?
DNS is the system that turns a name like example.com into an IP address your computer can actually connect to. If DNS fails, the site is unreachable even if the server is perfectly healthy — your browser literally doesn't know where to send the request.
Use the check.systems DNS lookup tool to query the domain from an external resolver. Look for an A record (IPv4 address) or AAAA record (IPv6). If the query returns no records, returns NXDOMAIN, or returns SERVFAIL, DNS is the problem. The domain's authoritative nameservers are either misconfigured, the domain has expired, or the DNS infrastructure is down.
If the DNS tool returns a valid IP but your browser still fails, the resolver your computer is using locally may be returning a stale or broken answer. That's what the next two sections fix.
Flush your DNS cache
Your operating system caches DNS answers to avoid repeating lookups for every page load. Most of the time that's helpful — occasionally it's the source of the problem. If a site's IP address recently changed (a server migration, a DNS update, a CDN cutover), your machine may still be holding the old address and trying to connect to a server that no longer answers.
Flushing the cache forces your OS to ask again. The command depends on your platform:
- Windows (Command Prompt as Administrator): ipconfig /flushdns
- macOS (Terminal): sudo dscacheutil -flushcache; sudo killproc -HUP mDNSResponder
- Linux (most modern distros): sudo systemd-resolve --flush-caches or on newer systems sudo resolvectl flush-caches
Browsers also keep their own DNS cache. In Chrome, visit chrome://net-internals/#dns and click "Clear host cache". In Firefox, restart the browser — that's the simplest way.
Try a different DNS resolver
By default, your computer uses whatever DNS resolver your ISP hands out via DHCP. ISP resolvers are notorious for being slow, hijacking failed lookups to serve ads, and occasionally returning stale or filtered answers. Switching to a public resolver fixes a surprising number of "the site won't load" complaints.
The three most reliable free public resolvers:
- 1.1.1.1 — Cloudflare. Fastest in most benchmarks, no logging.
- 8.8.8.8 — Google Public DNS. Extremely stable, anycast everywhere.
- NextDNS — configurable filtering (block ads, trackers, malware) with a free tier.
Set the resolver in your OS network settings (preferred), or directly on your router so every device on the network benefits. After changing it, flush your cache (see above) and retry the site. If the page loads now, your ISP's resolver was the bottleneck.
Traceroute the host
If DNS is resolving but the connection still fails or hangs, the next question is: where in the network path is the packet dying? Traceroute answers that. It sends probes with increasing time-to-live values and records each router along the way, so you can see exactly where traffic stops getting through.
Run the check.systems Traceroute tool against the hostname. A healthy trace shows a steady sequence of hops ending at the destination. If the trace stalls part way and shows asterisks (* * *) for the last several hops, something between that router and the destination is dropping packets — usually a routing problem at an ISP or transit provider you can't control, but at least you now know it isn't you.
You can also use the Ping tool to check whether the host responds to ICMP at all. Note that many production hosts block ping by default, so silence from ping isn't proof of an outage — but a successful ping combined with a failed HTTP request points squarely at the web server software.
Browser cache, extensions, and firewall
If only one site fails and everything else works, the problem is often local to your browser. Try the page in a different browser, or open an incognito/private window (which disables most extensions). If it works there, the culprit is a cached resource, an extension, or a stored cookie. Clear the site's data: in Chrome, open DevTools, go to Application > Storage > Clear site data.
Browser extensions — particularly aggressive ad blockers, privacy tools, and VPN extensions — can break sites by blocking critical scripts or rerouting traffic through dead exit nodes. Disable extensions one at a time to isolate the offender.
Local firewalls and antivirus software occasionally block specific domains they consider risky. Check the firewall's recent block log. If you're on a corporate or school network, content filtering may be silently dropping requests to whole categories of sites — that's not a fix you can apply yourself, but it's useful to know.
When it's the ISP (and what you can do)
If the site is up globally, DNS resolves correctly through a public resolver, and traceroute shows packets dying at one of your ISP's routers, you've found an ISP-side problem. There's no setting on your laptop that fixes a broken route inside someone else's network.
Practical options in this case: switch DNS to 1.1.1.1 in case it's a DNS-level block; try a VPN to route around the broken path entirely (any reputable provider with multiple exit points will do); call ISP support and give them the traceroute output so they can escalate to network operations rather than walking you through factory-resetting your router for the third time. The traceroute output is the single most useful piece of evidence you can hand a tier-2 engineer.
And if it's a recurring problem with one specific destination, it may be a peering dispute between your ISP and the site's transit provider. Those resolve on their own timeline (sometimes weeks). A VPN is the only reliable workaround in the meantime.
Related: DNS lookup tool · What is DNS? The internet's phone book · Network diagnostics guide