Site Can’t Be Reached on WiFi but Works on Cell: Your Domain May Be Flagged as Phishing
- Site can’t be reached on WiFi, but works fine on cell data? A DNS filtering service, most often Cisco OpenDNS or Umbrella, has likely flagged your domain as phishing.
- The block happens at DNS lookup, before your server ever sees the request, so your uptime monitor, your logs, and your error pages all look completely normal.
- Three symptoms together confirm it: a plain connection error instead of a branded block page, the visitor’s IP missing from every log you own, and the failure changing depending on which DNS resolver they’re using.
- You can confirm this yourself in under a minute with a handful of dig commands. Steps are below.
- The fix has two parts: get the person in front of you unblocked right away, then file a dispute so it clears for everyone else too.
- Why Does “Site Can’t Be Reached on WiFi” Happen When Cell Data Works Fine?
- What Three Symptoms Confirm a DNS Filtering Block?
- How Do You Check This Yourself in Under a Minute?
- Before You Dispute: Is Your Site Actually Clean?
- How Do You Fix a False Phishing Flag?
- Why Is This the Quietest Outage a Website Can Have?
- Frequently Asked Questions
Why Does “Site Can’t Be Reached on WiFi” Happen When Cell Data Works Fine?
The support message usually sounds like a router problem: “I can’t reach the site from my WiFi. It says the site can’t be reached. If I switch my phone to cell service, it loads fine.”
You check the obvious things first. The server is up. The CDN shows no blocks. Then you check the logs, and this is where it gets strange: the visitor’s IP never appears at all. Not blocked, not challenged. Only absent, as if the request was never sent.
It wasn’t. Cisco’s OpenDNS and Umbrella, one of the most widely deployed DNS filtering services on the internet (built into countless business networks, school districts, and home routers) had classified the domain as phishing. On any network using it, the DNS lookup itself returns Cisco’s sinkhole address instead of the real one. The browser tries to load HTTPS against that sinkhole, the certificate cannot possibly match, and the visitor sees a plain “site can’t be reached.” No block page. No error code. No log entry anywhere you can read, because the traffic never makes it past the visitor’s own DNS resolver.
Here is the part that should worry you more than one person’s WiFi complaint: it is never one person alone. Every visitor behind that filtering (every office, every school, every family router running “protection”) has been silently bouncing off your domain. They don’t email you about it. From where they sit, your site does not exist.
What Three Symptoms Confirm a DNS Filtering Block?
Three symptoms together point at DNS filtering and almost nothing else.
- “Site can’t be reached” is a connection-level browser error, not a branded block page. A firewall or CDN block usually shows you something. A DNS sinkhole fails the TLS handshake and shows nothing at all.
- The visitor’s IP appears in no log you own. Not your origin server, not your CDN, not your firewall. The request never left their network.
- The failure is resolver-specific. It works on cell data and fails on WiFi, or the other way around, because the two paths are using different DNS resolvers.
How Do You Check This Yourself in Under a Minute?
Ask a handful of public resolvers, including the filtered ones, what they think of your domain:
dig +short yourdomain.com @1.1.1.1 # Cloudflare dig +short yourdomain.com @8.8.8.8 # Google dig +short yourdomain.com @9.9.9.9 # Quad9 (security filtering) dig +short yourdomain.com @208.67.222.222 # OpenDNS standard dig +short yourdomain.com @185.228.168.9 # CleanBrowsing security
A healthy domain returns the same IP addresses everywhere. In the case that prompted this post, every resolver agreed except OpenDNS, which returned 146.112.61.108. Any address in the 146.112.61.x range is Cisco’s block page sinkhole. If you landed on this post because you searched that exact IP, that is your diagnosis.
You can even ask the sinkhole what it thinks you did wrong:
curl -s -H "Host: yourdomain.com" http://146.112.61.108/ | grep -oiE "phish|malware|blocked"
In our case, it returned “phish.” One word. Three weeks of invisible lost visitors.
One distinction matters here. If only the FamilyShield resolver blocks you, that is a content category setting on one network’s own filter, and it is worth checking with them directly. If the standard resolvers block you, as in this case, Cisco has flagged the domain itself, globally, for every Umbrella-filtered network on earth.
Before You Dispute: Is Your Site Actually Clean?
A classification dispute filed against a site that is genuinely compromised will fail, and it burns credibility you will want later. Spend fifteen minutes verifying first.
- Check Google Safe Browsing’s transparency report for your domain. A clean result there, alongside a Cisco-only flag, is a strong hint you are looking at a false positive.
- Verify core file integrity (wp core verify-checksums on WordPress).
- Search your uploads directory for PHP files that should not be there (find wp-content/uploads -name “*.php” should return nothing).
- Look for what phishing actually looks like: pages imitating a bank, a mail provider, or a delivery service. If a phishing kit ever lived on the site, you will usually find its remains.
If everything comes back clean, the most likely trigger is something mundane: a brand name domain on a newer top-level domain can be enough to pattern-match an impersonation heuristic. Machine classifiers make this mistake constantly, and the blast radius lands on every visitor behind that filter, not only the one who happened to notice.
How Do You Fix a False Phishing Flag?
Fix It for the Person in Front of You (Five Minutes)
Point their router or device DNS at 1.1.1.1 or 8.8.8.8, or, if they deliberately run OpenDNS themselves, add your domain to their own allow list. This restores their access immediately and confirms the diagnosis.
Fix It for Everyone Else (The Dispute That Actually Matters)
File a dispute with Cisco at the Talos Reputation Center (talosintelligence.com/reputation_center, free account required). Look up your domain, dispute the categorization, and lead with your evidence: a clean Google Safe Browsing result, verified platform integrity, no imitation content on the site, and a real business behind the domain name. Disputes typically resolve in one to three days.
Confirm the clearance the same way you found the problem:
dig +short yourdomain.com @208.67.222.222 # want your real IPs, not 146.112.61.x
Why Is This the Quietest Outage a Website Can Have?
Every other kind of outage announces itself: error pages, monitoring alerts, angry emails. A DNS reputation flag is the quietest failure mode a website has. Your uptime monitor says 100 percent. Your logs look completely normal. And a slice of the internet cannot find you at all.
The only reason this particular case surfaced is luck: the site owner happened to be sitting behind the same filter as his missing visitors. Most business owners never get that lucky.
The lesson worth adopting: domain reputation is infrastructure. Check your domains against the major filtering resolvers the same way you check SSL expiry, on a schedule, before a customer discovers it for you.
Frequently Asked Questions
