Every Nodetonet proxy is hosted by a specific physical edge server — the machine that owns the listening port your client connects to. In the proxy creation form there is a Server dropdown set to auto by default. For most users, leaving it on auto is entirely fine. For the rest, choosing explicitly is the difference between a 60 ms and a 400 ms round trip — and on latency-sensitive work, that gap compounds across every request you send.
TL;DR: Use auto unless you have a hard latency budget, are running bulk parallel connections, need a specific outbound IP for an upstream allow-list, or have compliance rules about where traffic may transit. If any of those apply, read on — this is the complete field guide to the Server dropdown.
What an edge server actually does
To understand why the choice matters, trace the full request path: your client connects to Cloudflare's anycast network, which hands the connection to the nearest Cloudflare PoP, which then forwards it to the edge server, which holds the WebSocket tunnel open to your paired mobile device, which exits to the target site. The edge server is hop two in that chain.
Two things are determined by which physical data-center the edge server sits in:
- Your latency from client to tunnel. Cloudflare anycast gets you to the nearest CF PoP quickly; but the CF PoP-to-edge leg is real geographic distance. A client in Singapore connecting to an edge in Frankfurt adds ~160 ms of avoidable latency.
- The source IP your upstream provider sees. This matters less for the target (targets see your mobile device's carrier IP, not the edge IP), but it is critical when you use upstream residential forwarding — the device-to-upstream leg originates from the edge server, so your upstream's IP allow-list must permit that edge's IP address.
In plain terms: the edge server does not change the IP the target website sees — that is always your phone's carrier IP — but it does determine how quickly requests travel there and what address your upstream sees as the source.
Available regions at a glance
The proxy creation form shows a live list of available edge servers. At the time of writing the fleet covers eight regions; check the dropdown for the current live list, or pull it programmatically via GET /api/v1/servers.
| Region | City / Country | Best for | Secondary use |
|---|---|---|---|
| EU-NORTH | Helsinki, FI | Nordics, Germany, Netherlands | Primary EU PoP; lowest latency across Northern Europe |
| EU-CENTRAL | Frankfurt, DE | Central and Western Europe | Backup EU PoP; good AS path to most European countries |
| EU-WEST | London, UK | UK and Ireland clients | Cross-channel work; lower latency to FR and ES than Frankfurt |
| US-EAST | New York, US | Eastern US clients | Also the best option for LATAM clients routing through North America |
| US-WEST | Los Angeles, US | Western US clients | APAC-via-US workflows; lower latency to AU than Singapore for some peerings |
| APAC | Singapore, SG | Southeast Asia, Australia, India | Only PoP east of Bahrain; catches most Asia-Pacific clients |
| ME | Bahrain, BH | Middle East, Turkey, Egypt | Gulf region; reasonable path to Central Asia |
| LATAM | São Paulo, BR | Brazil, Argentina, Chile | Lower latency to LATAM clients than routing through US-EAST |
The fleet grows over time. If you are scripting provisioning, always fetch the live list rather than hard-coding region codes.
How the auto algorithm works
When you leave the Server dropdown on auto, the panel picks an edge server based on two signals: the geographic region inferred from your account's panel session (geo-IP) and the current port-usage load on each eligible server. The result is the lowest-loaded server in your nearest region at the moment of creation.
Auto is the right choice when:
- Your client and your target are both reachable in under 200 ms from any major PoP — most consumer and SMB scraping use cases sit here.
- You do not have a hard latency budget. If your downstream task is "fetch one page, pause two seconds, repeat," the difference between a 60 ms and a 100 ms tunnel is invisible in production.
- You are running a single device or a small fleet and do not need to route upstream traffic through a specific source IP.
- You are exploring the platform for the first time — over-engineering your first proxy wastes time.
When to pin a specific edge server
Pin explicitly whenever one or more of the following conditions apply:
Latency-sensitive workflows
Sneaker drops, ad-tech bidders, real-time price monitors, and anything where every 50 ms has a material effect on success rate all benefit from pinning the PoP geographically closest to the client running the automation. Measure first (see the measurement section below), then pin.
High-concurrency parallel scraping
When you are running hundreds of simultaneous connections through the same edge, load matters. The Server dropdown shows a load indicator next to each option. Pick the edge with the most headroom rather than letting auto default to the geographically nearest one, which may already be busy. For bulk pool management see the guide on managing proxies at scale.
Upstream residential forwarding
If you chain Nodetonet to an external residential or datacenter provider via upstream forwarding, the traffic your upstream receives originates from the edge server's IP — not from your mobile device. Some upstream providers enforce IP allow-lists on their API endpoints. In that case, identify which edge IP corresponds to your allow-listed address and pin accordingly. You can verify the outbound IP any time with our proxy checker.
Compliance and data-residency requirements
Some enterprise workflows legally require that traffic not leave a named jurisdiction while in transit between the client and the panel. If you have such a requirement, pin to the edge inside the permitted region and document which server was selected. Auto provides no such guarantee.
A/B performance testing
Create the same proxy specification on two different edges, run identical workloads against both, and you get an honest measurement of the second-hop cost. This is useful before committing a large fleet to a new region.
How to measure latency before committing
A simple curl loop is enough to compare edges honestly before you create a proxy:
for srv in fra hel nyc sgp bah; do
echo "=== $srv ==="
curl -o /dev/null -s -w "connect:%{time_connect} total:%{time_total}
" -x http://user:pass@$srv.nodetonet.com:48888 https://api.ipify.org
doneRun this from the same host that will actually run your automation — cloud VM, co-located server, or laptop. The time_connect value is the raw TCP handshake to the edge; time_total includes the full round trip through the device to ipify and back. Pick the edge with the lowest time_total for your target, pin it, and move on.
For a broader connectivity check on an existing proxy, use our free proxy checker — it confirms the proxy is live, returns the exit IP, and shows latency from the checker's location.
Switching edge after the fact
You cannot change the edge server of an existing proxy. The listening port is allocated on — and physically tied to — a specific machine. To switch, delete the proxy and recreate it pointing at a different edge.
The good news is that the token and device binding is preserved: tokens and their paired devices live on the device record, not the proxy record. The only things that change when you recreate a proxy on a different edge are the connection string's hostname and port number. Update those in your client config and you are done.
Pro tip: if you manage a fleet of proxies via the Nodetonet REST API, store serverId as a parameter in your provisioning script rather than hard-coding it. Migrating an entire fleet to a new PoP then becomes a single variable change and a re-run of the script. See programmatic proxy creation in Python for a worked example.
Edge servers, mobile proxies, and the data plane
It helps to understand what the edge server runs. Nodetonet's architecture separates the control plane (the panel, API, billing, token management) from the data plane (the actual proxy traffic). Edge servers run the data-plane engine: they accept incoming client connections, maintain persistent WebSocket tunnels to paired Android devices, forward traffic through the device's cellular connection, and report usage back to the panel.
This architecture means that even if the panel is briefly unavailable, established proxy tunnels continue to serve traffic — the edge runs independently. It also means that adding a new region is an infrastructure operation: a new edge server joins the pool, the panel starts offering it in the dropdown, and existing proxies on other edges are unaffected.
For mobile proxies, the edge holds the WebSocket from your Android device. For HTTP tunnels, the edge (or a Windows .exe agent on a PC) terminates inbound HTTPS and forwards to your local service. In both cases, the edge-server choice affects latency between the public internet and the tunnel endpoint.
Token groups and edge diversity
A token group is a pool of mobile devices that Nodetonet distributes requests across using round-robin or least-connection selection. Within a token group, individual devices can be pinned to different edge servers — and this is a useful reliability pattern: if one edge has elevated load or goes through maintenance, devices on other edges continue serving traffic. See automatic failover for mobile proxies for how to set this up.
When you use rotating proxies through a token group, the exit IP changes with each rotation regardless of which edge the current device is on. From a targeting perspective, carrier, country, and city targeting via username modifiers still works the same way — the edge server is invisible to that mechanism.
Frequently asked questions
What's next
- How Nodetonet routes traffic — the full hop-by-hop path, so the latency numbers above make concrete sense.
- Monitoring tunnel health — once you have picked an edge, keep an eye on it.
- Programmatic proxy provisioning — set
serverIdat scale from a Python script. - Upstream residential forwarding — chain Nodetonet to an external provider, and why the edge IP matters there.
- Full feature overview — see everything Nodetonet offers beyond proxy hosting.