Why I Couldn't Access My Own Site (But My Phone Could): A Cloudways Auto-Ban Story

I sat down to work on Rev6 and couldn't load the site. Not a slow load, not an SSL warning — nothing. The browser just spun until it gave up. My first assumption was the usual suspect: the server was down.

Then I checked my phone, on the same Wi-Fi. Rev6 loaded instantly.

That one detail sent me down a much longer rabbit hole than I expected — and the actual cause had nothing to do with my laptop, my router, or even my ISP.

The Setup

Rev6 is hosted on Cloudways, which provisions on top of DigitalOcean. DNS resolved fine — the domain pointed to the correct droplet IP. So this wasn't a broken domain or expired DNS record. The problem was specifically about reaching that IP.

The Failed Attempts

I went through the usual network debugging checklist, and every single one came back clean:

1. Ping and curl to the server — both hung and eventually timed out on ports 80, 443, and even 22 (SSH). Not "connection refused," just total silence, as if the packets vanished.
2. General internet sanity check — Google, GitHub, Cloudflare all loaded instantly. So this wasn't a broken connection, just this one destination.
3. Local firewall (ufw/iptables/nftables) — checked the full ruleset, OUTPUT policy was ACCEPT, no rule matched the server's IP or any DigitalOcean range.
4. VPN or proxy — none active, no http_proxy/https_proxy env vars, no tunnel interfaces.
5. MAC-based router filtering — randomized my Wi-Fi adapter's MAC address entirely. Still blocked.
6. Hostname-based filtering — some routers key parental-control rules off the DHCP hostname instead of the MAC. Disabled hostname broadcasting, renewed the lease. Still blocked.
7. The router itself — logged into the ONT admin panel and checked every filtering section: IP Filter, MAC Filter, WLAN MAC Filter, Parental Control, Device Access Control. All disabled, all empty.

At this point every layer between my laptop and my ISP was confirmed clean. Whatever was blocking the connection wasn't local.

The Clue That Cracked It

The "works on my phone" comparison turned out to be misleading. When I checked my phone's actual public IP (via whatismyip.com), it came back as a completely different address in a different range than my laptop's real ISP-assigned IP — a sign that Brave's VPN feature was tunneling all my phone's traffic elsewhere. My phone was never a fair comparison; it simply wasn't taking the same path to the internet.

The real breakthrough came from testing the connection from a network entirely outside my ISP. From there, the request to the server didn't time out — it came back as an active refusal. That's a meaningfully different signal:

• From my home connection: total silence — no response at all
• From an outside network: an explicit "connection refused"

Silence usually means something in the path is dropping packets. An active refusal means the packets arrived, and something on the other end responded. That distinction pointed the investigation away from my network entirely and toward the server side.

The Real Issue: Cloudways Had Auto-Banned My IP

Cloudways includes a Bot Protection feature — AI-driven heuristics and CAPTCHA challenges meant to keep malicious bots off the server. It's a genuinely useful feature. It's also fully automated, which means it can ban a legitimate visitor without any human ever reviewing the decision.

Under Server → Security → Firewall, there's a blacklist table showing banned IPs, the country they're associated with, and the reason. Searching my own IP directly returned nothing — but filtering by country (Philippines) surfaced it immediately:

My own home IP had been silently banned for a full week after failing a CAPTCHA challenge — almost certainly an automated bot check I never even saw, triggered while browsing my own site.

The Fix

From the same Firewall screen:

1. Search for the banned IP (or filter by country if the exact IP search comes up empty)
2. Open the ⋮ actions menu on that row
3. Remove/delete the blacklist entry

Access was restored immediately — no server restart, no DNS changes, nothing else required.

Takeaway

When a site is unreachable but DNS resolves and the rest of the internet works fine, don't assume it's your network just because another device on the same Wi-Fi can get through — verify that device is actually taking the same path out to the internet first. A background VPN can make an "it works on my phone" comparison completely meaningless.

And when the destination is a managed host like Cloudways, remember that automated bot/security protections can ban you just as easily as an actual attacker. If everything on your end checks out clean, check the host's own security dashboard before assuming there's a deeper network problem — the block might already be sitting there in plain sight, just filed under "security."