If a landing page loads slowly in one country, while prices or language are displayed incorrectly in another — the problem is likely not with the site itself, but with the CDN or geo-DNS delivering the wrong node. We will explore how to check this independently in 8 regions without access to expensive enterprise monitoring — using proxies and a couple of free tools.
Why check CDN and geo-DNS
CDN (Content Delivery Network) and geo-DNS exist to deliver the nearest server to the user — this speeds up loading and often changes content based on the region: language, currency, prices, banners. The problem is that geo-targeting settings often break unnoticed by the site owner: the CDN provider updated the node map, the DNS record points to an outdated edge server, or the redirect rule works only for part of the IP range of a specific country.
For arbitrageurs, this is critical: if a landing page for Germany loads through a CDN node in the USA, the page opens 2-3 seconds longer — and this directly kills conversion in Facebook Ads and Google Ads. For SMM agencies and marketplace sellers, the problem is similar: a promo page may show the wrong currency or the incorrect version of the catalog if the DNS delivers the wrong region. Marketers testing localized campaigns often do not realize there is a problem until they receive complaints from users or see abnormal bounce rates in metrics.
Checking from 8 regions is a reasonable balance between coverage and time spent. This is enough to catch most routing errors: different continents, different levels of internet infrastructure, different CDN operators (Cloudflare, Akamai, Fastly respond to geo-requests differently).
How geo-DNS and CDN routing works
When a user accesses a site, their DNS request is processed not by one server, but by a geo-DNS system, which looks at the IP address (or its geographical database — GeoIP) and delivers the IP of the CDN edge node that is physically closer or logically assigned to that region. The CDN node then either serves cached content or proxies the request to the original server, applying geo-targeting rules — language substitution, currency, redirects to the local version of the domain.
The key point: all this logic is tied to the client's IP address. If you open a site from a regular home internet connection in Moscow, you cannot physically see what a user from Brazil or Vietnam sees. This is why a fair check requires an IP that actually belongs to the target region — not just a VPN with a "virtual" location, which many CDNs have long learned to recognize and ignore.
Here lies the difference between types of proxies. Cheap datacenter IPs are often found in the databases of known datacenters, and some CDNs — especially Cloudflare and Akamai — apply separate logic to them (sometimes even showing the default region instead of the local one). For accurate geo-targeting checks, it is better to use residential proxies — they are listed in GeoIP databases as regular home connections from a specific country, and CDNs treat them just like real users.
Which 8 regions to choose for testing
The set of regions should be tailored to your actual audience, but if you need a universal checklist for an international project, here is a working scheme that covers the main areas of CDN infrastructure:
| Region | Why check |
|---|---|
| USA (East) | Main node for most CDNs, speed benchmark |
| Germany | Dense network of edge nodes in the EU, checking GDPR redirects |
| United Kingdom | Separate currency/language after Brexit, frequent point of errors |
| Brazil | Weak CDN coverage in Latin America, long ping |
| India | High load on nodes, often reduced CDN rates |
| Indonesia / Vietnam | Checking Southeast Asia, growing arbitrage market |
| UAE | Middle East, often separate currency and language |
| Australia | Isolated geography, checking fallback node on failure |
If your audience is concentrated in other countries — the set should be adjusted according to the geo of advertising campaigns. The main principle: take points from different continents and with different densities of internet infrastructure to catch both "rich" CDN zones and regions with sparse edge nodes.
Tools for checking from different countries
For a comprehensive check, you will need a combination of three types of tools: proxies with the required geo-location, a way to send requests through this proxy, and a tool for analyzing the server response (headers, DNS, loading time).
| Tool | Task | Suitable for |
|---|---|---|
| Residential proxies | Emulating a real user from the country | Checking content and redirects |
| Mobile proxies | Checking mobile version of CDN delivery | Arbitrage, TikTok/Facebook Ads campaigns |
| Datacenter proxies | Quick check of node availability and server response | Technical speed monitoring |
| Dolphin Anty / AdsPower | Opening the site with the required geo, timezone, browser language | Visual checking of landing pages without code |
| curl / Postman | Analyzing CDN response headers | Technical specialists |
| nslookup / dig | Checking the IP that DNS actually returned | Geo-DNS diagnostics |
Step-by-step checking via proxy
Let's break down a practical algorithm that does not require coding — it can be performed by a marketer or arbitrageur independently.
- Obtain a list of IPs or a proxy connection for each of the 8 regions. For the purity of the test, it is important that these are real residential or mobile IPs, not server addresses — otherwise, the CDN may deliver a "technical" version of the content.
- Open a browser (regular or in an anti-detect profile) and connect the proxy for the first country in the network settings.
- Clear the browser cache and cookies before each visit — otherwise, the site may load a cached version from the previous geolocation.
- Open the target site and record: page language, currency, redirect to the local domain (e.g., site.com → site.de), total page loading time.
- Open developer tools (F12) → Network tab → refresh the page and check the server response headers: look for the fields
CF-RAY(for Cloudflare),X-Served-ByorX-Cache— they often indicate the code of the node that processed the request. - Repeat for all 8 regions and compile the results into a table: region, IP address, CDN node, loading time, content correctness.
For technical specialists, this same process can be automated via curl with proxy specification and header analysis:
curl -x http://user:pass@proxy_de.example.com:8000 -I https://example.com
curl -x http://user:pass@proxy_br.example.com:8000 -I https://example.com
# Check the headers CF-RAY, X-Cache, X-Served-By, Content-Language
# and compare values between regions
If the CF-RAY header contains an airport code (e.g., FRA for Frankfurt or GRU for São Paulo), you can verify how well the node corresponds to the expected region — a list of airport codes can easily be found in open Cloudflare directories.
Checking via anti-detect browser
For arbitrageurs and SMM specialists who are already working with multi-accounting, it is easier to integrate geo-CDN checking into the familiar process through Dolphin Anty, AdsPower, GoLogin, or Multilogin. Create 8 profiles, assign each a proxy from the corresponding country, set the correct timezone and system language for the region — this additionally eliminates false positives from CDN anti-fraud systems, which sometimes block content when the IP and browser timezone do not match.
This approach is convenient because you simultaneously check not only CDN routing but also how the site looks "through the eyes" of a real user — including the operation of advertising pixels, the correctness of price display in the required currency, and the loading speed of media content, which is most often delivered via CDN.
Common CDN geo-targeting mistakes
In practice, when checking 8 regions, the same problems are often discovered:
- Outdated CDN GeoIP database — the internet provider recently received a new block of IP addresses, but the CDN database has not yet been updated, causing users from country A to be served by a node from country B.
- Incorrect fallback node — when the nearest edge server fails, the CDN switches to a backup node in another region but does not return localized content.
- Cache of an old version of the page — after updating geo-targeting rules, the CDN continues to serve a cached version for the old region until the TTL expires.
- Conflict between DNS and CDN rules — DNS returns the correct IP, but at the CDN level, a different routing rule is set based on the Accept-Language header, which overrides geolocation.
- Blocking by IP type — some CDNs apply stricter checks to datacenter IPs, showing reduced or default content instead of localized content.
CDN and geo-DNS checking checklist
- Residential or mobile IPs prepared for all 8 regions
- Cache and cookies cleared before each visit
- Language, currency, redirects recorded for each country
- CF-RAY / X-Served-By / X-Cache headers checked
- Page loading time compared between regions
- Check repeated after 24-48 hours to rule out temporary failures
- Results compiled into a single table for comparison
Conclusion
Checking CDN and geo-DNS in 8 regions allows you to identify problems in advance that would otherwise only surface after user complaints or a drop in conversion in advertising campaigns. The main rule of such diagnostics is to use IPs that the CDN recognizes as real users from the target country, rather than technical datacenter addresses.
If you regularly test localized landing pages for Facebook Ads, TikTok Ads, or Google Ads, the optimal choice would be residential proxies — they provide an accurate picture of what a real user sees in each country. For checking the mobile version of the site and CDN performance on mobile traffic, it is also worth testing mobile proxies, while datacenter proxies are suitable for quick technical checks of server response speed.