Random or mixed geo means your proxy exits rotate across many countries, cities, and ASNs instead of holding a fixed location. To see where country, city, ASN and “random” sit on the same ladder, read proxy IP geolocation & targeting guide.
What “random/mixed geo” means
Random or mixed geo selects an exit from a large IP pool on each request or short session, without guaranteeing a specific country or city. The outcome is breadth of vantage points rather than location stability.
In practice, providers map your gateway to a pool that spans many regions and networks. Selection can be fully random, weighted, or filtered by allow/deny rules. Because the source changes frequently, repeat hits from the same /24 or ASN are less likely.
When to use random/mixed geo
Use random geo when you need many diverse vantage points and do not care which specific city or ISP is used. It is a sampling tool rather than a precision tool.
Common cases include global SERP or ad landing checks, large catalog or price discovery where geo bias would skew results, resilience testing where IP freshness matters, and edge routing or CDN reachability checks from many points.
How providers implement it (rotation)
Most vendors pair random geo with short sessions or single-request rotation. That way each hit is likely to emerge from a different subnet or ASN.
Typical controls include rotation by request for maximum spread and short sticky windows when a target enforces continuity. For when to use per-request switching vs short sticky windows, check proxy rotation types.
Buyer’s checklist
Pick a service that can prove diversity and let you shape the mix you receive.
- Pool diversity metrics. Ask for counts of unique /24s (or /48s for IPv6), ASN variety, and country distribution. Avoid pools dominated by one or two countries.
- Controls. Look for allow/deny lists to exclude restricted regions, optional weighting to steer toward or away from certain areas, and caps per country or ASN to prevent overconcentration.
- Session policy. Prefer rotation by request for wide sampling. Use short sticky sessions only when the target breaks without continuity.
- Concurrency hygiene. Spread threads across multiple gateways when available. De-duplicate by /24 or ASN on your side so you do not hammer a small slice of the pool.
- Compliance. Maintain denylists for embargoed or restricted regions and confirm your provider permits random-geo use in their Terms.
Setup tips that save time
The first lines under each heading give you the fast answers you need. Below are concise, practical steps to get consistent results from a random pool.
- Identify the gateway and auth. Confirm hostname, port, and whether you use IP allowlist or Username/Password.
- Select rotation. Use per-request endpoints when offered; otherwise set the shortest sticky window that still passes the target.
- Tag every hit. Record country, city, ASN, and subnet for each request; keep a running tally so you can spot skew.
- Throttle hot ranges. If you see too many hits from the same /24 or ASN, reduce concurrency for that slice or add it to a temporary deny list.
- Export and review. Produce a daily distribution report. If the mix is not what you expect, adjust weights or filters with your provider.
Note Always test proxies via HTTP/HTTPS requests (or through the target app), not ICMP ping.
Verifying the actual location
You should validate against multiple data sources because targets often rely on their own geo databases. A single lookup is not enough.
Use two or three third-party geo APIs and also check what the destination site detects on its side. Large services and CDNs may resolve location by their own PoPs, so compare the API result with what the target displays and treat discrepancies as normal in random pools.
Costs and network types
Expect different pricing and trust signals by network. Random residential or mobile endpoints are usually billed per GB and score as consumer traffic on many sites. Datacenter and ISP pools can be cheaper and sold per IP, port, or thread, but some targets treat them closer to hosting traffic. If you need price/behavior differences for DC, ISP, residential and mobile pools, go to proxy network types.
A small reference table:
| Network type | Typical billing | Usual trust profile | Notes |
| Datacenter | Per IP/port/thread | Often treated as hosting | Wide supply, cost efficient, may face stricter filters |
| ISP (Static Residential) | Per IP or port | Closer to consumer than DC | Fixed ranges routed by ISPs, good for stickier tests |
| Residential (Rotating) | Per GB | Consumer-like | High diversity, CGNAT is common |
| Mobile (Rotating) | Per GB | Strong consumer signal | Highest CGNAT, cell tower variance |
What random cannot do
Random geo cannot guarantee a city, ISP, or a stable IP for logins or carts. If your workflow needs continuity, you must switch to a fixed country or city and use sticky sessions. Random distributions are rarely uniform; to get a true picture you need large sample sizes and your own de-duplication.
Pitfalls and how to avoid them
These failures show up often and are preventable with a few guardrails.
- Overconcentration in one region. Solve it with caps per country and per ASN plus client-side de-duplication.
- Mismatch between geo APIs and target classification. Test with the target’s own logic and treat third-party geo as advisory.
- Too-long stickiness. Shorten the window until the target stays stable. Add a fallback to per-request rotation for sampling.
- Ignoring compliance. Keep a deny list for restricted regions and verify program rules before you start.
Quick decision guide
Use this compact map to choose a control for your next run.
| Your need | Control to favor |
| Max diversity and sampling | Rotation by request, no stickiness |
| Limited continuity (e.g., load a page sequence) | Short sticky window (seconds to a minute) |
| Bias away from specific regions | Allow/deny or weighting rules |
| Avoid repeat hits from same network | De-duplication by /24 or ASN |
FAQs
Does random geo mean I will never hit the same IP twice?
No. Random means the pool is broad and selection changes often, not that repeats are impossible. Use short sessions and client-side de-duplication to reduce repeats.
Can I exclude certain countries or networks?
Many providers support allow/deny lists or weighting. Ask for caps per country and per ASN if you need stronger controls.
Why does the detected location differ between services?
Different databases and CDN PoPs produce different views. Validate with multiple sources and check what the target itself reports.
Is random residential always better than datacenter?
It depends on the target. Residential and mobile often score as consumer traffic but cost per GB. Datacenter and ISP can be cheaper and faster to scale, though some sites score them as hosting.
When should I switch away from random?
Any workflow that needs a stable city, ISP, or session continuity should use country or city targeting with sticky sessions.
Related in this topic: