Two days after shipping geolocation testing with datacenter proxies, we started seeing failures. Sites that should have loaded fine from Germany were returning access denied pages. Geo-restricted streaming services were detecting our traffic as suspicious. E-commerce sites were serving captchas instead of checkout flows.

The problem wasn't our implementation. It was the nature of datacenter IPs.

Why datacenter proxies get blocked

When you route traffic through a datacenter proxy, the target site sees an IP address that belongs to a hosting provider like AWS, Google Cloud, or a commercial proxy service. These IPs are catalogued. Every major anti-bot service maintains lists of known datacenter IP ranges.

Sites blocking datacenter IPs aren't being paranoid. Scrapers, credential stuffers, and ticket bots all run from datacenters. Blocking those IPs is a reasonable defense. But it also catches legitimate automation like browser testing.

Our BrightData integration worked great for most sites. But for geo-restricted content - streaming services, regional e-commerce, location-locked financial platforms - the datacenter IPs were getting flagged faster than we could rotate them.

The VPN difference

A VPN gives you an IP address from an ISP, not a datacenter. When your test connects through NordVPN's servers in Germany, the target site sees an IP that looks like a regular German internet user. Same ISPs, same IP ranges, same trust signals.

This isn't about "hiding" anything. It's about accessing content the same way real users do. Your German customers aren't connecting from AWS. They're connecting from Deutsche Telekom, Vodafone, or their home ISP. A VPN mimics that.

We integrated NordVPN as our primary geolocation provider. They have servers in 60+ countries, stable connections, and IPs that don't get mass-flagged the way datacenter proxies do.

How we run VPNs in the cloud

Running a VPN in a cloud environment is trickier than running one on your laptop. Click "Connect to Germany" in your desktop app and NordVPN reroutes all your traffic through their German servers. Simple.

In a server environment, you need more control. You can't just tunnel everything - your test infrastructure needs to talk to databases, queue services, and AI providers. Routing all that through a VPN server in Turkey would be slow and wasteful.

Our approach: Docker sidecar containers as local proxies.

Here's the architecture. When you run a test from Germany:

We spin up a Docker container configured to connect to NordVPN's German servers
That container exposes a local HTTP proxy (just a port on localhost)
Playwright connects through that local proxy for browser traffic only
Everything else - API calls, AI inference, screenshot storage - goes direct

The result: your test browser appears to be in Germany, but all the supporting infrastructure stays fast.

┌────────────────────────────────────────────────────┐
│                   Test Server                       │
│                                                     │
│  ┌─────────────┐    ┌──────────────────────────┐   │
│  │ Test Runner │    │  VPN Container           │   │
│  │             │    │  ┌──────┐  ┌───────────┐ │   │
│  │ AI Calls ───┼──────────────────▶ Internet  │   │
│  │ (direct)    │    │  │Proxy │  │  NordVPN  │ │   │
│  │             │    │  │:8888 │  │  Tunnel   │ │   │
│  │ Browser ────┼──▶ │  └──┬───┘  └─────┬─────┘ │   │
│  │ (proxied)   │    │     └──────┬─────┘       │   │
│  └─────────────┘    │            ▼             │   │
│                     │     German IP Exit       │   │
│                     └──────────────────────────┘   │
└────────────────────────────────────────────────────┘

Why sidecar containers instead of system VPN

You might wonder: why not just run NordVPN directly on the host and route everything through it?

Concurrent countries. We run tests from multiple countries simultaneously. One user tests from Germany, another from Brazil, another from Japan. With sidecar containers, each test gets its own VPN connection. System-level VPN would force us to serialize by country.

Isolation. If the VPN tunnel drops, only the test using that tunnel fails. Other tests keep running. A host-level VPN failure would take down everything.

Startup time. VPN containers spin up in 25-40 seconds and stay alive between tests. The first test to Germany pays the startup cost, subsequent tests reuse the connection. System VPN would need full reconnection for each country switch.

Cleaner infrastructure. Docker containers are disposable. No persistent VPN state, no leftover routing rules, no iptables conflicts. Stop the container, the connection is gone.

This pattern is common in cloud-native environments. Sometimes called "sidecar proxy" or "service mesh adjacent" - though ours is simpler than a full mesh. The core idea: encapsulate network behavior in containers rather than configuring host networking.

Performance characteristics

VPNs add latency. The traffic has to travel to NordVPN's servers before reaching the target. A test to a German site from our US servers goes:

US Server → NordVPN Germany → German Website → back

Instead of:

US Server → German Website → back

In practice, this adds 50-150ms per request. For a test that makes 50 network requests, that's 2.5-7.5 seconds of overhead. Noticeable, but not prohibitive.

The trade-off is worth it when the alternative is getting blocked. A fast test that returns "Access Denied" isn't useful.

Tips for minimizing latency:

Use US (no proxy) when possible. If geo-restriction testing isn't the point, skip it. Direct connections are always faster.
Pick the closest country. Testing EU compliance? Germany is closer to our servers than Greece.
Batch geo tests. Run all your Germany tests together so the container stays warm.

When to use VPN vs proxy vs direct

Direct (US, no proxy): Fastest option. Use for most tests where geography doesn't matter. This is the default.

VPN (NordVPN): Use when testing geo-restricted content, localized pricing, or region-specific features. The IPs look residential, so sites trust them.

Datacenter proxy (BrightData): Still useful as a fallback or for sites that don't do aggressive IP filtering. Slightly faster than VPN, more country coverage.

We handle this automatically. Select a country, and we route through the best available provider for that region. If VPN fails, we fall back to proxy. You don't need to manage the routing yourself.

110+ countries, real VPN IPs

NordVPN gives us coverage across all major markets:

Americas: United States, Canada, Mexico, Brazil, Argentina, Chile, Colombia, Costa Rica

Europe: UK, Germany, France, Spain, Italy, Netherlands, Poland, Sweden, Switzerland, Czech Republic, and 20+ more

Asia Pacific: Japan, Australia, Singapore, South Korea, Hong Kong, Taiwan, India, Indonesia, Thailand, Vietnam

Middle East: Israel, UAE, Turkey

Africa: South Africa

The full list is in the dashboard. Coverage continues expanding as NordVPN adds servers.

Getting started

Same setup as before - geolocation is configured at project or test plan level.

Project default:

Go to Projects in your dashboard
Edit your project
Select a country from the Location dropdown
Save

Test plan override:

Go to Test Plans
Edit the test plan
Expand Advanced Settings
Select a different country

Scheduled runs and API triggers all respect these settings. The VPN routing happens automatically based on your configuration.

Included with Custom plans

Geolocation testing - VPN and proxy - comes bundled with Custom plans. No per-country fees, no metered usage. Pick any of the 110+ countries and run as many geo-targeted tests as you need.

If you're testing geo-restricted content and running into access issues with your current setup, reach out and we'll get you sorted.

Testing geo-restricted sites? Stop getting blocked. Try Test-Lab with NordVPN geolocation and test what your international users actually see.

NordVPN Geolocation: Testing Geo-Restricted Sites Without Getting Blocked