When Cloudflare Is Up but Your Site Is Down
Your server is running. Nginx is healthy. But the site is down from your home ISP. What BGP routing and Cloudflare anycast have to do with it.
Your server is healthy. All services running, ports open, logs clean. But the browser just spins.
You check twice. Everything is fine on the server side. You pull out your phone, switch to a hotspot, load the same URL. The site loads instantly.
The server was never down. Your path to it was.
The IP is the same. The physical server is not.#
Cloudflare (and most CDNs) use a technique called anycast. A single IP address like 104.21.86.41 is announced from hundreds of Cloudflare servers worldwide. Your request doesn’t go to one specific machine; it goes to whichever Cloudflare server your ISP routes you to.
Same IP. Different physical machine. Entirely dependent on your ISP’s routing decisions.
BGP and the path your ISP chooses#
The internet is not one network. It’s thousands of independent networks (called autonomous systems) operated by ISPs, cloud providers, and large organizations, all connected through a protocol called BGP (Border Gateway Protocol).
BGP is how these networks share reachability information: “I can reach this IP range, via this path.” Every ISP has its own BGP routing table and picks paths based on cost, peering agreements, and latency. Two ISPs in the same city can take completely different routes to the same destination IP.
In this case, my home ISP was routing to Cloudflare’s Jakarta PoP (CGK). My mobile ISP was routing to a different PoP, likely Singapore. One of those paths was broken; the other wasn’t.
What a PoP is#
PoP stands for Point of Presence: a physical data center where Cloudflare runs edge servers. Cloudflare has over 330 of these globally. Traffic from Indonesian ISPs typically lands at the Jakarta PoP or nearby Southeast Asian ones.
A PoP can degrade for many reasons: hardware failure, network congestion, or a BGP misconfiguration upstream. Cloudflare’s response is to re-route traffic to healthy PoPs. During that transition, anyone whose ISP routes to the affected PoP will see the site as unreachable.
[Home ISP] ──► BGP routing ──► Cloudflare Jakarta (CGK) [DEGRADED] ✗
[Mobile ISP] ──► BGP routing ──► Cloudflare Singapore (SIN) [healthy]
│
▼
your serverThe IndiHome pattern#
This is not a one-off. The Cloudflare Jakarta PoP (CGK) has had documented incidents in June 2025, July 2025, September 2025, and January 2026, each resulting in degraded access or full re-routes, with IndiHome (Telkom) users consistently among the most affected.
The root cause is peering. IndiHome does not have a direct peering agreement with Cloudflare. Traffic takes indirect paths through transit providers, which means instability at CGK hits Telkom users harder and recovery takes longer compared to ISPs with direct peering.
A separate issue: Komdigi (Indonesia’s Ministry of Communication and Digital Affairs) maintains a government blocklist called TrustPositif. Some Cloudflare IPs have been caught in it. If the site loads fine on a hotspot but not after flushing DNS and switching resolvers, your ISP may be blocking specific Cloudflare IPs at the government’s direction, not just routing poorly.
How to diagnose it#
Check the server first, then work outward:
- Verify services are running:
systemctl status your-service nginx - Test locally:
curl http://localhost:PORT/— if that works, the app is fine - Check cloudflarestatus.com ↗ for incidents in your region
- Run
curl -v https://yourdomain.com 2>&1 | grep -E 'Trying|SSL|Connected'to see which Cloudflare IP you hit - Try from a different network (hotspot, VPN) — if it loads there, the problem is between your ISP and Cloudflare
In this case, cloudflarestatus.com showed “Jakarta (CGK) - Partially Re-routed.” A direct hit to the server IP returned the correct page. The hotspot loaded everything fine. The server had nothing to do with it.
What to do#
Usually: nothing. “Partially Re-routed” means Cloudflare is already handling it. The incident resolves on its own as traffic gets redirected to healthy PoPs.
If you need access from the affected connection right now:
-
Flush your local DNS cache. On macOS:
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder -
Switch your DNS resolver to
1.1.1.1or8.8.8.8 -
Use a VPN — it puts you on a different network with different BGP routing, likely hitting a healthy PoP
None of these are guaranteed, but each one changes your path through the network.
The internet is not binary. A site being unreachable for you does not mean it is down globally. Your ISP’s route to the CDN edge matters as much as the server itself.