My IP got blacklisted by an automated security layer and I had
That one discrepancy sent me into a massive troubleshooting rabbit hole. If the site worked on my phone but not my laptop on the same network, it had to be something local. Or so I thought.
The troubleshooting checklist
I didn't want to guess, so I went through a systematic deep dive to rule out every possible failure point in my local environment:
1. Network connectivity: I ran ping and curl against the server. Both timed out on ports 80, 443, and even SSH (22). It wasn't a "connection refused" error; it was total silence, as if my packets were being swallowed by a black hole.
2. Local firewall rules: I audited my ufw and iptables configurations. My OUTPUT policy was set to ACCEPT, and there were zero rules targeting the DigitalOcean IP ranges.
3. VPN/Proxy check: I verified that no background VPNs or proxy environment variables were active.
4. Router-level filtering: I went deep into the ONT admin panel. I checked MAC filtering, IP filtering, parental controls, and device access lists. Everything was disabled. I even tried randomizing my Wi-Fi adapter's MAC address to bypass any hardware-based blocks.
Everything on my end looked clean. The problem wasn't my laptop, my router, or my ISP.
The "Phone" fallacy and the breakthrough
The "it works on my phone" clue was actually a red herring. When I checked my phone's public IP using a lookup tool, I realized it was on a completely different subnet than my laptop. My phone was running a built-in VPN feature that tunneled my traffic through a different gateway. My phone wasn't a "control group"; it was taking an entirely different path to the internet.
The real breakthrough happened when I tested the connection from a completely different network (a cellular hotspot). From that external network, the request didn't time out—it returned an explicit connection refused.
This distinction was critical for my diagnosis:
- Home connection: Total silence (packets are being dropped).
- Outside network: Active refusal (packets arrive, but the server actively says "no").
This shifted the entire investigation from my local network to the server-side security configuration.
The culprit: Cloudways Bot Protection
The issue turned out to be the automated security heuristics used by Cloudways. They use an AI-driven Bot Protection system designed to trigger CAPTCHAs or block IPs that exhibit suspicious behavior to prevent brute-force attacks and scrapers.
Because it is fully automated, it can misidentify a legitimate user as a malicious bot and blacklist them instantly without any human intervention.
I finally found the smoking gun by logging into the Cloudways dashboard and navigating to Server → Security → Firewall. I searched for my specific IP, but it didn't show up initially. I had to filter the blacklist by my country (Philippines), and there it was:
- IP: [My Home IP]
- Purpose: Blacklisted
- TTL: 1 week
- Reason: Blacklisted for CAPTCHA failure
Apparently, a few failed attempts to clear a challenge or some unusual traffic patterns from my local setup triggered the automated ban. If you are managing high-security environments or using managed hosting with heavy AI-driven security, always keep an eye on your firewall logs. Sometimes the "server is down" feeling is just a very efficient security bot doing its job a little too well.