Locations & network stories

Why region matters for latency and for trust

Where a cloud phone is hosted affects two different things, and people usually only think about the first. Latency is the obvious one: the closer the seat is to you and your proxy exit, the more responsive the remote session feels when you're operating it live. A warm session you actually touch every day shouldn't feel like a satellite call.

The subtler, more important factor is account trust. An account's plausibility depends on its geography making sense — the region of the seat, the region of the proxy exit, and the region the account claims to be from should tell one coherent story. A "local" account whose signals scatter across the map is a weaker account. Region choice is part of building an identity that hangs together, not just a performance knob.

How to pick a region for your audience

The guiding principle is simple: host near the audience the account is pretending to be part of, not near your own desk. If the account's story is "a person in a particular country," the seat and — more importantly — the proxy exit should match that story.

• Match the account's claimed geography first. That coherence matters more than shaving milliseconds off your own latency.
• Then optimize latency within what's consistent, so daily operation stays comfortable.
• Keep it stable. Picking a region and staying put beats hopping around, which reads as a device that keeps physically moving.

If you operate accounts across several markets, think in terms of one coherent region-plus-proxy story per account rather than one global default for all of them.

Mobile IP vs datacenter IP

Region is only half the network story — the type of exit matters as much as its location. A seat hosted in the right country but exiting through an obvious datacenter IP still tells a mismatched story for a consumer social account. The region says "here" while the IP class says "server farm."

This is why the proxy carries most of the weight. A sticky mobile exit in the target region is the strongest match for an account whose story is "a person on mobile data." High-quality residential works when mobile isn't available for that geography. The region you host in should complement that exit, not contradict it. Getting the country right but the IP class wrong is a common and avoidable mistake — see the platform page for how per-device proxy routing fits together.

Region and physical devices together

Region choice interacts with the cloud-versus-physical split covered across the site. For the social stack on cloud seats, region plus proxy is a configuration decision you make per account — pick the geography that matches the story, attach the matching exit, and keep it stable.

For apps we steer to physical handsets — neo-banks and attestation-heavy banking apps — the device's real location and real network are part of what the app inspects, so "region" is a more concrete, physical fact rather than a routing choice. The practical takeaway: treat region as a per-account decision on cloud, and as a genuine physical constraint on hardware. Match each app to the environment, then make its geography coherent within that environment.

Honesty about regions and labels

We keep region labels generic and honest on purpose. You won't find invented city names, named datacenters, or a map studded with flags implying a presence we won't stand behind. Region selection is about matching your accounts' geography to a coherent hosting-and-proxy story — that's the part that affects your outcomes — not about collecting an impressive-sounding list of locations.

If a specific region is available for your use case, that's a concrete question worth asking directly rather than inferring from marketing copy. What we'll commit to here is the principle: pick the region that makes your account's story coherent, pair it with the right proxy exit, and keep it stable. Start from pricing to provision a seat, then set its region and proxy before first login.