← All guides

Why a website works for some people but not others (and how to tell which problem you have)

Updated 22 September 2026 · by Cassian Wei · 4 min read

It is the most maddening kind of outage: you post a link, half the replies say "works great", the other half say "it just spins". You check it yourself — fine. You post "fixed!" — and the same people say it still doesn't load. Nobody is lying and nobody is crazy: the site genuinely is up for some visitors and down for others, because something between the two groups differs. This guide lists the usual suspects in order of how often we see them, and a quick test for each.

1. It works over http:// but not https:// (the classic)

Modern browsers try https:// first — Chrome, Firefox and Safari all upgrade a bare typed domain, and links shared from most apps carry https explicitly. If your server (or redirect service) answers plain HTTP on port 80 but the TLS handshake on port 443 hangs or fails, you get a perfect works-for-me split: anyone whose client falls back to (or was given) http sails through; anyone whose client insists on https stares at a spinner until timeout.

The most common way to end up here: registrar URL forwarding. Several registrars' free "domain forwarding" answers HTTP only — an https request to the forwarded domain never completes, because nothing is terminating TLS for it. The forward "works" when you test it (you typed the bare domain, your browser quietly tried http) and fails for the person who clicked an https link.

Test it explicitly, both schemes:

curl -sv -m 10 http://example.com/  -o /dev/null   # completes?
curl -sv -m 10 https://example.com/ -o /dev/null   # hangs at "TLS handshake"?

If http answers (often a 301/302 to somewhere else) and https times out, that's your split. Fix: turn on TLS for the forward if your registrar supports it, put the domain behind any TLS-terminating proxy/CDN, or simply share the destination URL directly instead of the forwarded domain.

2. DNS: some resolvers have the old answer

You moved hosts or changed an A record. DNS caches expire per-resolver: people whose resolver already refreshed reach the new server; everyone else is still being sent to the old IP — which may be dead or serving the old (broken) site. This one heals by itself within the record's TTL, but with a long TTL "itself" can take a day.

dig +short example.com @1.1.1.1
dig +short example.com @8.8.8.8   # different answers = propagation split

3. IPv6 says one thing, IPv4 another

If the domain has an AAAA record pointing at an address that is misconfigured or dead, visitors on IPv6 networks (a lot of mobile) fail while IPv4 visitors connect fine — or the reverse. Happy Eyeballs hides mild cases but not a hard-broken one. Test each family: curl -4 vs curl -6.

4. A firewall or WAF blocks some networks

Bot-protection rules, country blocks, and "under attack" modes classify visitors. People on VPNs, datacenter IPs, or the wrong side of a geo rule get a 403 or an endless challenge; everyone else never sees it. The tell: the blocked group gets a fast, definite error (often 403) rather than a timeout.

5. Old devices don't trust the certificate

After a certificate change, older phones and smart TVs that lack the new CA chain (the Let's Encrypt root transition burned many) throw certificate errors while current browsers are fine. The split correlates with device age. An outside TLS check shows the chain being served.

6. Caches: the "fixed but still broken" special

Service workers, aggressive CDN caching, or a captive browser cache can pin an old broken version for returning visitors while new visitors get the fixed one — the exact inverse of the http/https case. If hard-refresh or a private window fixes it, it was a cache; purge the CDN and, if you ship a service worker, make sure it updates itself.

The 60-second triage

  1. Get an outside vantage. Run the domain through an independent instant check — it tries the real https URL from a cloud edge and shows status, latency and the failure detail (timeout vs 403 vs TLS error), which already separates cases 1, 4 and 5.
  2. Try both schemes yourself with the two curl commands above. An http/https split is case 1, and it will not heal on its own.
  3. Compare resolvers (case 2) and IP families (case 3) with dig/curl.
  4. Ask one "broken" person for the exact error text. Timeout → 1 or 3; certificate warning → 5; 403/challenge → 4; works in private window → 6.

Stop finding out from your replies

Every case above except the caches was invisible to the owner precisely because their own browser was in the lucky group. An outside monitor doesn't share your caches, your resolver, or your http fallback: a free 60-second-interval monitor requests the real https:// URL like a stranger would, and emails you on the first failed check — with the failure detail that tells you which of the six problems it is. If the site is someone else's, a back-up watch emails you once when it answers again.

Watchpup is free uptime & cron monitoring — 1-minute checks, heartbeats, TLS/domain expiry, status pages, alerts everywhere. Sign up, try the live demo, or read more guides.