Geo-blocking works by looking up each source address in a table that maps IP ranges to countries, rather than by inspecting anything the client actually sends. That makes it one of the cheapest controls a DDoS test is built to exercise, and one of the easiest to misjudge. It drops or challenges traffic from regions an application does not serve, shrinking the attack surface when the customer base is genuinely local. Enforcement usually sits at the CDN edge or WAF, keyed off a commercial or registry-derived GeoIP database.
What the lookup actually knows
A GeoIP database does not know where a person is. It knows which organisation an address block was registered to, where that block has been observed in use, and what the database vendor inferred from both. For a fixed broadband line that is usually right at country level. It degrades in predictable places. Mobile carriers route many subscribers through a small number of gateways, so a phone can geolocate to wherever the carrier's egress sits. Satellite internet users appear wherever their ground station is. Corporate VPNs and cloud egress make a whole office look like it is in another country. And IPv4 blocks are bought and sold, so a range can move continents while the database lags behind.
The control only means something when the source address is real. For a spoofed Layer 3 or 4 flood the "country" is whatever the forged address happens to map to, which is noise. For a reflection attack the sources are real but they are the reflectors, scattered across every country with open servers, not the attacker. Geo-blocking earns its keep at Layer 7, after a TCP handshake has proven the address can receive packets. Even there, the address may belong to a proxy.
Why it matters under attack
Two facts decide whether a geo rule helps during a flood.
The first is where it runs. A geo rule on the origin firewall drops the traffic after it has crossed the uplink, so a volumetric flood from a blocked country still fills the pipe it was meant to protect. The same rule at an edge with more capacity than the attack removes the load before it reaches anything that can saturate. A test result for "geo-blocking enabled" is meaningless without knowing which of those two it was.
The second is that the attacker chooses the country. Commercial residential proxy networks sell exit nodes filtered by country, and a botnet of compromised home devices naturally contains machines in the target's own market. An L7 flood aimed at a UK-only service can be sourced entirely from UK consumer addresses, at which point the geo rule passes all of it and is doing exactly what it was configured to do.
Where it does help is as a fast, reversible incident lever. If a flood is concentrated in regions where you have almost no customers, a temporary country-level challenge (softer than a block) can shed most of it in minutes while slower controls are tuned. That is only safe if you already know what share of your real traffic comes from each region, which is a baseline traffic question, not a geo one.
What a DDoS test measures
A test answers three questions. Does a flood sourced from allowed countries, including through in-country proxies, still reach the origin, and how does the rest of the stack cope when it does? Where is the rule enforced, and does it shed load before or after the constrained link? And what does the rule cost: which legitimate flows (travelling staff, roaming phones, payment providers and webhooks calling from data centres abroad, your own monitoring) fall into a blocked region and break?
The incident version is worth timing separately: how long it takes to apply a country rule under pressure, and how quickly it can be rolled back if it catches the wrong people. The same reasoning applies to a remote-access gateway whose users are a known population, which DDoS testing for VPN gateways works through.