Is a Website Down for Everyone or Just Me? How to Check Properly

You cannot load a site, and the only thing you know is that it fails on your screen. Before you restart your router or email support, you need to answer one question: is the failure on the site's side, or somewhere between you and it? This guide shows how to answer that reliably in a few minutes, and what to fix when the answer is "just me".

It works whether you are a visitor trying to reach someone else's site or an owner who has just been told "your site is down" by a customer.

Why one failed page load proves very little

A browser tab says "can't be reached" for many unrelated reasons. Your own device, your Wi-Fi, your ISP's DNS resolver, a VPN, a corporate proxy, a security product, the destination's CDN edge node closest to you, and the origin server itself are all in the path. Only the last two are "the site being down". Everything else can fail while the site is perfectly healthy for the rest of the world.

The opposite error is also common. Site owners often test from their own office, where a DNS cache or a hosts-file entry points to a working server, and conclude everything is fine while visitors see an outage.

So the goal is to compare your view with independent views.

Step 1: Read the exact error

The wording narrows the search before you run any test.

A 5xx error that you can read in the browser already proves something important: your DNS, network and TLS worked, and a server answered. That answer came from the site's infrastructure, so it is almost certainly down for everyone, or at least for some of the traffic. The error guides cover each code in detail. Connection-level errors are explained in connection refused, timed out and reset explained.

Step 2: Get an outside opinion

The fastest test is a request from somewhere that is not your network. Options:

• Open the site on your phone using mobile data with Wi-Fi turned off. This swaps your entire local path for a different one.
• Ask a colleague or friend in another city or ISP.
• Use an external checker. The HTTP स्टेटस चेकर requests the URL from the server side and reports the status code and headers it receives, and Down From Where is built for the question of whether the site responds from outside your location. The वेबसाइट हेल्थ चेक adds DNS and TLS results in one pass.

Interpret the results carefully:

Step 3: Test from the command line

Commands separate the layers, which a browser cannot do.

# DNS: what does your resolver say vs. a public one?
dig +short example.com
dig +short example.com @1.1.1.1
dig +short example.com @8.8.8.8

# Connection: can you reach the port?
nc -vz example.com 443

# Full request with timing and the exact status line
curl -v --max-time 15 -o /dev/null https://example.com/

# Force IPv4 or IPv6 to detect a half-broken dual-stack setup
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://example.com/
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://example.com/

On Windows PowerShell, Resolve-DnsName example.com -Server 1.1.1.1 and Test-NetConnection example.com -Port 443 do the same jobs.

How to read the results:

• Your resolver returns nothing but 1.1.1.1 or 8.8.8.8 returns an address. Your ISP or router DNS is the problem. Switching resolvers or flushing the cache fixes it.
• Different resolvers return different IPs. You are watching DNS propagation or a split-horizon setup. The DNS चेकर shows the spread, and how long DNS propagation takes explains why.
• DNS is fine but nc times out. Something blocks or drops traffic to that IP and port: a firewall on your side, a regional filter, or the server being offline.
• curl -4 works but curl -6 hangs (or the other way around). The site has a broken IPv6 or IPv4 record. Browsers try both and usually recover, but some clients hang for seconds. This is a real site-side defect for a share of visitors.

When it is "just me": the usual culprits

Work from the cheapest fix to the most invasive.

Local DNS cache

Stale entries are the single most common reason a migrated site "does not work" for one person. Flush them:

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux with systemd-resolved
resolvectl flush-caches

Browsers also keep their own DNS cache. In Chrome you can clear it at chrome://net-internals/#dns, though restarting the browser achieves the same.

A hosts-file override

If you or a developer previously pinned the domain to a test server, your computer ignores DNS entirely. Check /etc/hosts on macOS and Linux, or C:\Windows\System32\drivers\etc\hosts on Windows, for the domain name and remove stale lines.

VPN, proxy and "security" software

A VPN exit node may be blocked by the site, rate limited, or located in a region where the site is restricted. Disconnect it and retry. The same applies to a corporate proxy, a school filter, and antivirus products that inspect HTTPS. A quick test is to try the site on a different device on the same Wi-Fi: if the second device works, the first has a local setting.

Your IP address is blocked

Sites protected by a WAF, fail2ban or a hosting provider's abuse rules can block an address after suspicious activity, including previous failed logins. Signs are a 403 or timeout from one network but not others, and the site loading instantly on mobile data. Find the address you are presenting with What Is My IP, and if you own the site, check your firewall for it. The Blacklist Checker helps if the address is on public abuse lists.

Wrong system clock

TLS certificates are valid only within a date range. A laptop with a dead clock battery or a wrongly set date will show certificate errors on every HTTPS site. Fix the date and time, and the errors disappear.

Browser state

Cookies, extensions and cached redirects occasionally break a single site. Try a private window with extensions disabled. If that works, clear the site's cookies and cached data. A cached 301 redirect pointing to a dead address is a well-known cause of "it works in every browser but this one".

Your ISP or route

If everything above checks out and other people on the same ISP also fail while the rest of the world works, the problem is routing or a regional filter, and you cannot fix it. Use a different network or wait. Running mtr -rw example.com or traceroute example.com gives you evidence to pass to the ISP.

When it is "everyone": what to do as the owner

If outside checks confirm the failure, move to the server side. Identify the layer first: no answer at all points to DNS, the network or a stopped server, while a 5xx response points to the application. The master troubleshooting walkthrough is Why is my website down?. If the site sits behind Cloudflare and you see a numbered 52x page, go to Cloudflare 520 to 526 errors explained.

Check that you are not the one causing the outage

Before you start changing server settings, rule out these self-inflicted problems:

1. Did a DNS change or nameserver switch happen recently? Compare authoritative and cached answers with dig.
2. Did the domain or certificate expire? Look at WHOIS and the SSL Checker.
3. Did a firewall or security plugin start blocking the monitoring IPs and some visitors?
4. Did a deployment or plugin update coincide with the first failure?

Tell customers something

If it is a real outage, a short, honest status message does more good than silence. A dedicated page hosted away from your own infrastructure is ideal, which is what status pages are for.

When to ask for help

• You are a visitor and the site is clearly down for everyone: wait, or look at the company's social account or status page. There is nothing for you to fix.
• You are a visitor and only your network fails: contact your ISP or network administrator, and give them the traceroute or mtr output.
• You are an owner and the site fails everywhere with timeouts or refusals: check your host's status page and open a ticket with the exact URL, error text and start time.

अगले कदम

Related tools and guides:

• Down From Where to compare views from different locations
• HTTP स्टेटस चेकर for the response code and headers
• DNS चेकर to spot resolver disagreements
• अपटाइम मॉनिटर so you hear about outages before visitors do
• Why is my website down?

सामान्य प्रश्न

What does it mean if a site is up for an external checker but down for me?

It means the site's server is responding to at least one location, and the failure is on your side or on the route between you and the site. Check your DNS resolver, VPN, proxy, firewall and hosts file, and try another network such as mobile data.

Can a website be down for only some countries?

Yes. Causes include a CDN edge node having problems, geo-blocking rules, regional routing faults and DNS answers that differ by location. That is why a single check from one place cannot prove a site is up everywhere.

Why does a site load on my phone but not my laptop on the same Wi-Fi?

Both share the router and ISP, so the difference is on the laptop: a cached DNS entry, hosts-file line, VPN, proxy, browser extension or security software. Try another browser, then flush DNS.

Is clearing browser cache enough to fix a down site?

Only when the cache is the cause, for example a cached redirect or stale certificate state. If the server is returning an error to everyone, clearing your cache changes nothing, so confirm with an outside check first.

How do I find out the moment my own site goes down?

Run an external monitor that requests the site regularly and alerts you through email or chat when it fails. The अपटाइम मॉनिटर is the tool for this, and how to reduce false alerts explains how to keep those alerts trustworthy.

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.