Scope note: this article explains the mechanisms behind regional restrictions and why they produce inconsistent results. It is not a guide to circumventing access controls, which commonly breaches the terms you agreed to and, in some jurisdictions, other rules as well.
Geoblocking is usually described as "the site checks your IP address", which is roughly a third of the story. In practice a restriction can be evaluated at several different points — the resolver, the CDN edge, the application, the payment processor, the app store — and each of those points reads a different signal to decide which country you belong to. When the signals disagree, the result is the partial and confusing behaviour most people actually encounter.
What signals determine your apparent country?
At least nine, read at different layers by different parties.
| Signal | Read by | Typical accuracy | Common failure |
|---|---|---|---|
| IP address via geolocation database | CDN, application | Country level usually good, city level much weaker | Reassigned ranges, stale data |
| CDN edge location | The CDN itself | Reflects network topology, not geography | Nearest edge may be in another country |
Accept-Language header |
Application | Language preference, not location | A UK-configured browser abroad |
| Browser timezone and locale | Client-side scripts | Device setting | Trivially inconsistent with the IP |
| Account registration country | Application | Whatever was entered at signup | Never updates when you move |
| Card issuing country (BIN) | Payment processor | Reliable for the card | Diverges from the user's location |
| Billing address | Payment processor | Reliable for the account | Same divergence |
| App store storefront | App platform | Tied to the store account | Independent of device location |
| SIM / carrier code | Mobile apps | Reliable for the SIM | Roaming and eSIM complicate it |
The important structural point: no single party evaluates all of these. The CDN sees the IP but not your card. The processor sees the card but not the edge that served the page. Nobody reconciles the answers, so a service can simultaneously treat you as being in two countries in two different subsystems.
How does IP geolocation actually determine a country?
By inference from registration and routing data, not by measurement.
Geolocation databases are built by combining regional internet registry allocation records, autonomous system ownership, BGP routing announcements, latency triangulation between measurement points, and corrections submitted by network operators and users. The result is a best estimate, refreshed periodically.
That construction explains the failure modes:
- Address ranges get reassigned between operators and countries, and databases lag the change by weeks or longer.
- Carrier-grade NAT on mobile networks puts thousands of subscribers behind a small pool of addresses registered wherever the carrier chose.
- Corporate networks route traffic out through a central gateway, so every branch office appears to be at head office.
- IPv4 and IPv6 can map differently on the same connection, so the answer changes depending on which protocol the request used.
- Satellite and some business connections are registered at an administrative address unrelated to the terminal's position.
Country-level accuracy is generally good and city-level accuracy is substantially worse — which is why regional restrictions are usually drawn at national boundaries even when the underlying licence is more granular.
Where in the request path does the block happen?
Earlier than most people assume, which is why blocks respond instantly and uniformly.
| Layer | Enforced by | What you see |
|---|---|---|
| DNS resolution | Resolver, or a mandated national filter | The name does not resolve, or resolves to a notice page |
| Network path | ISP filtering, often on IP or on the TLS server name | Connection times out or resets |
| CDN edge | The site's CDN, before the origin is contacted | Instant "not available in your region" |
| Application | The site's own logic, after authentication | Catalogue differs, or a feature is disabled |
| Payment | Processor and issuer rules | Browsing works, subscribing fails |
| App distribution | App store storefront rules | The app is not listed for your account |
The CDN edge case is the most common for commercial services. Because the decision happens at a point of presence near you rather than at the origin, the block is applied consistently and with no latency — and it is why the same URL can return a normal page and a refusal within a few hundred kilometres of each other.
Why do restrictions exist in the first place?
Three different reasons, which produce three different behaviours.
Licensing. Distribution rights are sold by territory. The service is not blocking you so much as it lacks the right to serve that title where you are. The typical symptom is a changed catalogue, not a blocked site.
Regulatory compliance. A jurisdiction imposes obligations — age assurance, content rules, reporting — and the operator concludes that serving that market is not worth the compliance cost. The typical symptom is a withdrawal notice or a verification wall.
State-mandated filtering. The restriction is imposed on the network rather than chosen by the service. The typical symptom is that the site is unreachable while other sites work normally, and the service itself is unaware you tried.
Distinguishing them is genuinely useful, because they are attributable to different parties. A catalogue difference is a rights issue with the service; an unreachable domain is a network issue outside the service's control.
Why do the signals disagree so often?
Because they were never designed to be consistent, and each is maintained by a different party for a different purpose.
Your IP reflects where your traffic exits the network. Your card reflects where your bank is. Your app store account reflects where you were when you created it. Your account country reflects what you typed at signup, possibly years ago. None of these updates when another changes, and no protocol reconciles them.
For a user, the practical reading is diagnostic rather than actionable: when something works partially, identify which signal the failing step is reading. Browsing failing points at IP or network; subscribing failing points at the card; a missing app points at the storefront; a changed catalogue points at licensing. That tells you which party to ask, and whether the problem is one that can be resolved at all.