A site that loads for you and fails for customers in one country is almost never “down”. Something between those customers and your origin is refusing, misrouting, or misresolving their requests, and it usually leaves a fingerprint in the error they see. Get the exact error first. It will save you hours.
Step One: Get the Error, Not the Complaint
“It doesn’t work in Germany” can mean five different failures. Ask the affected user (or test yourself, below) which of these they get:
| What they see | What it usually means |
|---|---|
| A branded block page, or Cloudflare “Error 1009” | A deliberate country rule, probably yours |
| HTTP 403 with no explanation | A firewall or bot-protection rule matching their region or network |
| The browser’s own “site can’t be reached” / DNS error | Name resolution failing in that region |
| A timeout, or a connection reset | Routing, a network-level block, or a sick CDN edge |
| The page loads, but broken or ancient | A CDN edge serving stale or partial content |
The first two mean something answered and said no. The last three mean the request never got a proper answer. That split decides where you look next.
Test From the Country Yourself
You can’t debug a regional problem from your desk, because your desk isn’t in the region. Three ways to get a real vantage point, cheapest first:
- A VPN exit in that country. Crude, and some VPN ranges are themselves blocked, which can mislead you. Good enough to reproduce a geo-block.
- A public measurement network. RIPE Atlas runs thousands of hardware probes worldwide and lets you run DNS, ping and traceroute measurements from probes in chosen countries. It’s the neutral way to answer “does this fail from real networks in Brazil?”
- A monitor that already probes from there. If you have one, you may have history showing exactly when the failures started, which beats any test run today.
When you reproduce it, save three things: the full error, the IP address your domain resolved to from that location, and the response headers if there are any. Most of the diagnosis below is reading those.
The Causes, in the Order Worth Checking
A Country Rule You Forgot You Wrote
Start with yourself, because it’s the quickest to rule out and the quickest to fix. Security tools make country blocking a one-line rule. Cloudflare’s WAF, for example, documents blocking by country, continent, or network (ASN) as a standard custom rule, and a visitor who hits one sees Error 1009, “Country or region banned”.
These rules get added during an attack and never removed. So check every layer that can hold one: your CDN or WAF, your host’s firewall panel, security plugins (some WordPress security plugins offer country blocking), and any .htaccess or nginx geo module config a previous developer left behind.
Bot Protection That Scores a Region as Risky
Subtler than a country rule. Bot-management systems weigh the reputation of the visitor’s network, and some mobile carriers, universities and whole national ISPs share IP addresses behind carrier-grade NAT. One abusive user on a shared address can get thousands of legitimate ones challenged or blocked. The symptom is a 403 or an endless challenge loop that affects one country’s mobile users and nobody else. Your WAF’s event log, filtered by that country, will show it.
DNS Answering Differently There
If the error is a DNS failure, or the resolved IP differs from yours, look at resolution. Recent DNS changes are the usual suspect: resolvers around the world cache your old records until the TTL runs out, so for a while different countries genuinely see different addresses. Geo-DNS and load-balancing records can also send one region to a pool that’s unhealthy. We covered why this class of failure is so easy to miss in DNS, the invisible outage.
One CDN Edge Having a Bad Day
CDNs serve each region from nearby edge locations. When one edge misbehaves, only the users routed to it notice. The response headers help here: most CDNs stamp a header naming the edge or data center that served the request (Cloudflare’s cf-ray header, for instance, ends in a three-letter code for the data center that handled the request). If the failing requests all name the same edge and the working ones don’t, you’ve found it. That’s the CDN’s problem to fix, so open a ticket with the header values attached.
The Network Won’t Carry the Traffic
Last and least fixable. Timeouts from one country with your DNS, CDN and firewall all clean point at routing or a deliberate network-level block, whether by an ISP or a government. A traceroute from the affected region shows where packets stop. If your hosting provider’s IP range has been blocked wholesale, moving to a different provider or putting a CDN in front is often the only practical fix.
Why Most Uptime Monitoring Misses This
Here’s the uncomfortable part. A website not accessible in some countries often sails straight past uptime monitoring, and some of that is by design.
We probe from up to 17 cities, grouped into three regions (US East, EU West and Asia Pacific, listed with their addresses on our probe IPs page). A monitor is checked from the cities in its own region. And when one city fails a check, FlareWarden re-checks from other cities before calling it an outage; if any of them gets a healthy answer, the failure is treated as a false alarm and nobody is paged.
We built it that way deliberately, because single-location failures are overwhelmingly probe noise: a congested route, a flaky resolver, a blip between our network and yours. Our piece on false-positive downtime alerts explains why paging on them does more harm than good. The trade-off is real, though. A genuine block that affects one country looks, to a consensus system, exactly like noise. We’d rather tell you that than pretend otherwise.
What you do get is the evidence:
- The live view shows each probe city’s latest result and latency. A city that keeps failing or is suddenly far slower than its neighbours is visible there, even when it never becomes an incident.
- Refusals are named per city. If a probe city receives 401, 403, 407, 451 or similar, the monitor records it as blocked, not down, and the monitor page lists the refusing cities with the status code and how many times it happened in the last 24 hours. A country rule or bot wall catching one of our cities shows up there.
Know which cities your monitors actually use; the probe IPs page lists them per region. If a country that matters commercially sits far from all of them, be honest with yourself about that gap and test it directly with a public measurement network on a schedule.
Stopping It Recurring
Most regional outages trace back to a change, so tie checks to changes. After any WAF rule, DNS edit, or CDN configuration change, test from at least one other continent before calling it done. Review country rules quarterly and delete the ones nobody can justify. And when a regional complaint comes in, check the per-city history before trying to reproduce it, because the problem you’re chasing may have started three days ago.
Key Takeaways
- Get the exact error first. A block page, a 403, a DNS failure and a timeout point at four different layers.
- Check your own rules before anyone else’s. Country blocks added during an attack are the most common cause and the easiest to forget.
- Headers and resolved IPs are the evidence. Save them from the failing location; they identify the edge, the record, or the rule.
- Consensus monitoring won’t page on one country, by design. It filters out probe noise, which means a real single-region block needs you to read the per-city results.
- Test from another continent after every network change. That’s where regional breakage is born.
See which cities can and can’t reach your site, and get paged only when the outage is real. Start monitoring free with FlareWarden: 15 monitors, multi-city checks, no credit card required.