How To Load Test A Website From Different Locations And Ip Addresses

Author bio: Valentin Ghita handles technical writing, marketing, and research at Anonymous Proxies (anonymous-proxies.net). He writes about proxies, web data, and the technical side of digital marketing.

Your load test says the site handles 5,000 requests per second, then real traffic from three continents tells a different story. The gap usually comes from the test itself. Every request originated from one machine on one network with one IP address, so the system never faced production conditions. The rate limiter saw a single client, the CDN answered from a single edge, and geo-routing never fired at all. This guide covers how to load test a website from different locations and IP addresses with tools you already run, JMeter, k6, or Locust, pushed through proxies instead of a fleet of cloud regions. One assumption applies throughout: you’re testing infrastructure you own or are explicitly authorized to test. It drives the tooling choices below and marks the line between a test and an attack.

Why single-location load tests give misleading numbers

A generator in one place measures one network path, so latency and congestion describe your test box’s route, which no real user shares. Keep-alive makes it worse: after a few seconds every request rides warm TCP connections with TLS already paid, a cost real clients pay constantly.

A rate limiter or WAF sees one IP hammering the API and either throttles the run early or, because you allowlisted the box, never gets tested. Load balancers hashing on client IP pin everything to one backend, so your headline number describes a single server. And a CDN answers the whole run from one warm edge cache, so the origin barely participates.

What proxied load testing can and cannot reveal

Proxies in different cities let you simulate traffic from multiple regions without renting servers on five continents. Each worker exits from a distinct IP in a real location, which activates the behaviors keyed on source address: per-IP rate limits, IP-hash balancing, geo-DNS steering, WAF rules, regional cache selection.

A datacenter proxy sits in a rack with clean fiber, though, so it says little about a phone on congested 4G, and proxy latency includes the proxy’s own hop. Treat those numbers as relative, and lean on real user monitoring for ground truth.

Choosing a proxy type: why datacenter IPs fit self-owned targets

Most proxy comparisons obsess over detection. Residential IPs look like home users and cost a premium because some sites block datacenter ranges. None of that applies when the target belongs to you: allowlist your test IPs in the firewall and reputation buys you nothing.

You’re paying for throughput, stability, and low added latency instead, and datacenter proxies win on each. ProxyWing measured typical datacenter response times under 200ms, against 500ms to 2s for residential. Servury found datacenter capacity 5 to 10x cheaper for high-bandwidth workloads. Since reputation is off the table, the most cost-effective way to generate distributed load is high-throughput datacenter IPs spread across the regions you care about. Vendors such as Anonymous Proxies offer dedicated datacenter IPs with unlimited bandwidth, which suits sustained load generation.

Routing JMeter, k6, and Locust through proxies

Decide the connection pattern first. A rotating endpoint gives you one hostname while the exit IP changes per request, which maximizes diversity with zero per-worker configuration. A static list gives each worker a fixed IP, which you need whenever an assertion depends on knowing which IP sent what, as in the rate-limit tests below.

JMeter

Pass proxy settings at launch:

jmeter -n -t plan.jmx -H proxy.example.com -P 8080 -u user -a pass

The flags cover the whole JVM, so several static IPs means several instances, each pointed at a different proxy. Each HTTP Request sampler also exposes proxy fields in its Advanced tab for finer control.

k6

k6 reads the standard environment variable, one proxy per process:

HTTPS_PROXY=http://user:pass@de1.example-proxy.com:8080 k6 run test.js

Ten source IPs means ten processes; split virtual users across them and merge the results.

Locust

Locust already runs as master and workers. Start each worker with its own HTTPS_PROXY, or set self.client.proxies inside the user class to assign proxies in code.

One detail trips people up: hostname resolution. You want it happening at the proxy, and HTTP proxies do that through CONNECT, but with SOCKS5 you need socks5h so DNS exits from the proxy’s location too, or your geo-DNS tests resolve from the wrong country.

Testing per-IP rate limits and geo-routing behavior

Say the API documents 100 requests per minute per IP. Pin four static IPs, push three to 120 requests in one window, and hold the fourth at 80 as a control. This is the cleanest way to test API rate limiting from different IPs, since every source and count is deliberate.

A run matching this table proves the limiter keys on individual IPs and isolates clients. If the control IP starts collecting 429s, your limiter is bucketing by subnet or globally, which is worth discovering before a customer does. Check the Retry-After header on the 429s while you’re in there; well-behaved clients depend on it.

Geo-routing uses the same method with location instead of volume. Send single requests through proxies in each region your DNS or anycast setup should recognize, then read the header naming the serving node: cf-ray on Cloudflare, x-served-by on Fastly, or a custom X-Backend header you add. A Frankfurt exit landing on a US origin means your steering policy and real geography disagree.

Reading results and avoiding false positives

Physics sets a floor: Sydney to a Virginia origin costs roughly 200ms round trip before your stack does anything, so a 250ms p50 from Australian proxies is not a bug. Record a single-request baseline per region before ramping and judge load results against it.

The proxy adds a hop of its own. Measure it on a trivial endpoint both ways:

In this example the proxy tax is a fixed 16 ms. If latency through the proxy grows under load while the direct path stays flat, the bottleneck is your system, not the route.

Two more traps. Client libraries retry on 429s and timeouts by default, so a retry storm inflates counts until you’re measuring your own retry policy, not the server. Set retries to zero unless retries are the subject. Regional edge caches start cold too, so early minutes overweight misses; report hit and miss latencies separately.

FAQ

Should I use residential or datacenter proxies for load testing?

Datacenter. Residential IPs exist to blend in on sites that filter datacenter ranges, and you are not filtering yourself. The one testing case where residential exits earn their cost is functional: checking whether fraud or bot rules treat residential traffic differently. That’s a correctness check at low volume, not a load test.

How many IPs do I actually need?

Enough to exercise the behavior under test, usually dozens rather than thousands. Per-IP limit checks need a few hot IPs plus a control. Load balancer distribution needs several times your backend count. Geo tests need one or two exits per region. Scale IPs with your assertions rather than raw volume; one datacenter IP can carry enormous throughput.

How is this different from a DDoS attack?

Authorization, intent, and control. You own the target or hold written permission, ideally with your host’s load-testing policy acknowledged. Your goal is finding limits so you can raise them. The run is scheduled, ramped gradually, watched live, and wired to a kill switch. Pointing this tooling at infrastructure you don’t control removes all of that and is illegal in most jurisdictions.

Putting it into practice

Distributed sources turn a load test from a bandwidth exercise into a rehearsal of production behavior. Route the tool you already know through datacenter proxies in the regions that matter, pin static IPs where assertions need them, and let a rotating endpoint cover bulk diversity. Baseline each region and the proxy hop before ramping so you never chase phantom latency. Keep every run authorized, controlled, and observable, and the only surprises left will be the ones you wanted to find.