A single-device proxy is the simplest and most deterministic mode on Nodetonet: one token bound to one physical device, so every request you make exits through the same SIM, on the same carrier, from the same IP — until you deliberately trigger a change. That predictability is a feature, not a limitation. For a whole class of real-world tasks — account management, stateful scraping, geo-verification — it is exactly what you need.
TL;DR: if your workload would break or look suspicious if the exit IP changed mid-flight, choose a single-device proxy. If it actively wants a fresh IP on every request, choose a rotating token group instead.
How a single-device proxy works on Nodetonet
When you install the Nodetonet agent app on an Android phone and pair it, the panel issues a token — an opaque credential string that the agent exchanges for a persistent WebSocket connection to the nearest edge server running the Nodetonet data plane. That edge connection stays alive as long as the phone is online.
When you create a proxy and point it at that token, the panel provisions a listener port on the edge and binds it permanently to that device's tunnel. The connection string you receive — something like http://u8x2:p7q1@sub42.nodetonet.com:48888 — is glued to that one device for the lifetime of the proxy. Every TCP connection your tool opens to that endpoint is forwarded down the phone's mobile data uplink and exits from the carrier's CGNAT pool, giving the destination a genuine mobile IP.
You can use either HTTP/HTTPS or SOCKS5 — both are served from the same listener, so you choose the protocol that fits your tool. Per-client controls let you add username/password auth, an IP allowlist, domain allow/deny rules, a data quota and a thread (concurrency) cap, all without touching the proxy endpoint itself.
Single-device vs a rotating pool — the key differences
It helps to see both modes side-by-side. A rotating pool — called a token group in Nodetonet — gathers several device tokens under one label; each new connection is dispatched to a different device using a round-robin or least-connections algorithm. Same endpoint URL, different physical exit IP per session.
| Property | Single-device proxy | Rotating token group |
|---|---|---|
| Exit IP stability | Fixed until you rotate manually | Changes each session / on a timer |
| Session continuity | Full — one device, one IP, one session | Requires sticky mode (-session-XXXX) for continuity |
| Throughput ceiling | One device's uplink (typically 20–80 Mbps) | Scales with pool size |
| Carrier / geo targeting | Exact — you pick the device's SIM | Steered with username modifiers (-country-tr, carrier tag) |
| Best for | Logins, stateful flows, precise geo-tests | High-volume scraping, multi-account scale-out |
| Concurrent devices needed | One | Two or more for meaningful distribution |
Neither mode is universally superior. They are complementary tools. Many production set-ups use a single-device proxy for the login step and a rotating pool for the subsequent crawl. For a full explanation of the rotating model, read rotating mobile proxies — when to use them.
Three situations where single-device is the right pick
1. Logged-in account work and sensitive logins
Anti-fraud systems at social platforms, e-commerce sites and financial apps watch for IP changes as a strong signal of account takeover. A login from London followed milliseconds later by an action from Istanbul triggers an immediate flag. A single-device proxy eliminates that risk: the device's SIM provides a consistent exit point that looks like one person sitting in one location all day.
The same logic applies to multi-account management. Each account should appear to live on its own trusted device. Pair a dedicated phone per account, issue one token per phone, and each session has a separate, stable identity rooted in a real carrier IP. You can apply a per-client username and password to each proxy so accounts never cross-contaminate, and optionally lock each to a specific domain allowlist.
2. Stateful and long-lived protocol sessions
WebSocket connections, streaming APIs, IRC and SSH all maintain a single open TCP socket across many exchanges. If the proxy mid-session suddenly switches the exit IP — as a naive rotating pool would — the server on the other end sees a new, unrecognised source address and drops the connection. A single-device proxy holds the same IP for the life of that socket, so the protocol never notices the proxy is there.
The same applies to multi-step checkout flows, CAPTCHA-solution sequences and any scraping pipeline where a series of requests must come from the same identity to pass server-side session checks. Use a single-device proxy to keep the identity stable; use a sticky session only when you truly need the flexibility to swap devices while still pinning identity within a time window.
3. Precise geo-targeting and carrier verification
When you need to see exactly what a user on Turkcell in Istanbul sees — the local ad creative, the localised price, the carrier-specific feature flag — a rotating pool is imprecise. You want one device with one known SIM. A single-device proxy gives you exactly that: the exit IP is the SIM's real operator IP, carrying the real ASN and the real city co-ordinates that geo-targeting systems read. Run our free What is my IP tool through the proxy after setup to confirm the carrier and location are exactly what you expect.
Choosing the right protocol: HTTP or SOCKS5
HTTP/HTTPS is the default choice for browsers, curl, Playwright, Puppeteer and most scraping frameworks. The proxy speaks the CONNECT method, so TLS is end-to-end and the exit IP is just a forwarding hop.
SOCKS5 works at the TCP level and forwards any protocol — game clients, SSH tunnels, custom binary protocols, UDP applications. If your tool can speak SOCKS5, it usually gives slightly lower overhead than HTTP CONNECT for non-web traffic. Nodetonet serves both from the same device, so the choice is entirely yours. See HTTP vs SOCKS5 — which to pick for a deeper comparison.
Per-client controls you get out of the box
Every proxy you create sits under a proxy client record in the Nodetonet panel. That record carries the following controls, each adjustable without touching the proxy endpoint:
- Username / password auth — unique credentials per client so sub-users or third parties never share secrets.
- IP allowlist — restrict which source IPs may authenticate. Useful for locking a proxy to a single server.
- Domain allow / deny list — limit or block the domains the proxy may reach, enforced at the edge.
- Data quota — a hard cap in MB/GB/TB; the proxy stops accepting connections once the limit is reached.
- Expiry date — automatically deactivate the client after a set date, perfect for time-boxed reseller access.
- Thread (concurrency) limit — cap the number of simultaneous connections through this client to protect the device from being overwhelmed.
This combination makes single-device proxies safe to hand out to reseller sub-customers via the white-label system, or to hand to a team member with scoped access to just one device.
TCP/IP fingerprint spoofing
Beyond the exit IP, advanced detection systems inspect the TCP/IP stack fingerprint — window size, TTL, option ordering — to infer whether a connection is coming from a genuine mobile device or a server pretending to be one. Nodetonet edge nodes support TCP/IP fingerprint spoofing, adjusting the connection parameters to match a real mobile client profile. Combined with a genuine carrier IP, this gives you the closest possible match to an organic mobile user on the target's telemetry.
The soft ceiling — and when to upgrade to a pool
A single device means a single mobile data uplink. The practical throughput depends on the phone's chipset, the carrier's network conditions and the cell site's congestion, but you should plan for roughly 20–80 Mbps and a finite number of simultaneous TCP connections before the device's kernel starts queuing. That limit is invisible to the panel — it forwards everything — and shows up as climbing latency rather than a hard error.
When you hit that ceiling, the right move is not to push harder; it is to pair a second (or third) phone and drop all tokens into a token group. Nodetonet's router spreads connections across the pool using least-connections selection with automatic failover if a device goes offline. You get horizontal scale without changing a single endpoint URL in your tool. Read round-robin device selection for detail on the dispatch algorithm, or if you are running many devices, see bulk operations for managing large proxy fleets.
Setting one up in minutes
- Install the Nodetonet agent app on an Android phone and follow the on-screen pairing steps — the token appears in the panel automatically. The full walkthrough is at your first token and Android pairing.
- In the panel, create a new proxy, select the token for your device, choose HTTP or SOCKS5, and optionally add a client with auth credentials.
- Copy the connection string and paste it into your tool, script or browser extension.
- Verify the exit IP and carrier with Proxy Checker or What is my IP.
Billing is prepaid credit on Nodetonet — no monthly subscription, and an idle proxy costs nothing. You only spend credit when traffic actually flows. If you are comparing options, see how Nodetonet stacks up against Bright Data, Smartproxy and Oxylabs.
What to read next
- Rotating mobile proxies — when to use them — the natural upgrade from a single device.
- Sticky sessions explained — pin a session identity inside a rotating pool for a defined time window.
- Token groups — creating device pools — how to scale from one device to many.
- HTTP vs SOCKS5 — which to pick — choose the right protocol for your toolchain.
Ready to try? Create a free account and pair your first device in minutes, or browse the full feature list to see everything Nodetonet can do from one panel.