How Nodetonet routes traffic — the full path of a single request

When you paste a Nodetonet connection string into curl and hit enter, six distinct systems coordinate to deliver that one request. Each hop adds a handful of milliseconds; together they form a chain that determines latency, reliability and which IP the target actually sees. Understanding it is the difference between "it works, ship it" and "I have no idea why my latency spiked to 800 ms today."

This post walks the full path of a single HTTPS GET — end to end, with the actual wire format at each hop — and then explains what you can and cannot control.

The five-hop data path at a glance

Here is the full route every request takes:

  +-----------+
  |  Client   |  (your scraper / browser / Postman)
  +-----+-----+
        |  1) TCP connect to sub42.nodetonet.com:48888
        v
  +------------+
  | Cloudflare |  2) Anycast PoP — TLS termination (HTTPS) or raw forward
  +-----+------+
        |  3) TCP forwarded to physical edge server
        v
  +------------------+
  |  Edge server     |  4) Auth check, sticky lookup, device selection
  | (socks5Server)   |  5) JSON frame pushed down persistent WebSocket
  +-----+------------+
        |  Always-open TLS WebSocket (device dials out to panel)
        v
  +-----------+
  |  Device   |  6) Unwrap frame, open TCP to target
  | (Android) |
  +-----+-----+
        |
        v
  +-----------+
  |  Target   |  (api.ipify.org, instagram.com, etc.)
  +-----------+

Hop 1 — your client to Cloudflare

Your tool opens a TCP connection to a hostname like sub42.nodetonet.com on a proxy port such as 48888. That hostname resolves via DNS to a Cloudflare anycast address, meaning the TCP SYN packet lands at whichever Cloudflare point-of-presence is physically closest to your client. If you are running a scraper in Frankfurt, that is typically the FRA PoP; from Singapore it would be SIN.

For HTTPS proxies, TLS terminates at the Cloudflare edge — your credentials travel over an encrypted channel even before reaching Nodetonet infrastructure. For raw HTTP and SOCKS5, Cloudflare Spectrum forwards the byte stream without parsing it, so the end-to-end TCP is preserved intact.

Hop 2 — Cloudflare to the edge server

Cloudflare forwards the TCP stream to the physical edge server that was assigned port 48888 at proxy-creation time. This is often the hop people forget when diagnosing latency. If your scraper is in Berlin but your edge server is in Singapore, every single request crosses Eurasia twice — once inbound, once for the response. Picking the edge server closest to your client (not closest to your target) is the single biggest latency lever you have. See choosing the right edge server.

Nodetonet edge servers run the data-plane logic independently from the panel, which is why devices can keep tunnelling traffic even if the panel web UI has a brief hiccup. The edge and panel communicate over a separate internal channel for configuration, not for every byte of proxy traffic.

Hop 3 — auth, sticky lookup, and device selection

The edge server runs a process called socks5Server (despite the name, it handles HTTP, HTTPS and SOCKS5 on the same port). When a new connection lands, three things happen synchronously before any bytes are forwarded:

1. Auth. The proxy username and password are matched against the stored proxy record. Per-customer credentials and IP allow-lists are enforced here — a mismatched credential returns a 407 immediately.
2. Sticky lookup. If the proxy has sticky sessions enabled, the panel hashes the session key — derived from a -session-XXXX username suffix, a header, or the source IP — and checks whether there is already a binding to a specific device. If yes, that device and only that device must handle this request. Read the full detail in sticky sessions explained.
3. Device selection. If no sticky binding applies, the panel selects a device from the token group using round-robin or least-connection, depending on configuration. If no device is online, the connection is rejected cleanly with a 502 — no hang, no timeout. See how round-robin device selection works.

Per-client controls — quota, thread limits, expiry, domain allow/deny — are also evaluated at this stage. If a client has hit its quota limit or its thread cap, the new connection is refused before any traffic flows.

Hop 4 — the WebSocket tunnel to the device

Every paired Android device holds open a persistent TLS WebSocket back to the edge server at all times. That is how the panel knows the device is online — the green dot flips the instant the socket drops. The panel never needs to dial out to the device; the device dials in and keeps the channel alive.

When the device is selected, the edge server pushes a small JSON command frame down this existing connection:

{"op":"connect","cid":"a3f","host":"api.ipify.org","port":443}

Subsequent bytes from the client are wrapped as data frames:

{"op":"data","cid":"a3f","b64":"..."}

The device replies symmetrically; the edge server unwraps and writes back to the client TCP socket. This framing means multiple concurrent requests can share the same WebSocket over multiplexed connection IDs (cid values), which keeps connection overhead low even under high concurrency.

The always-open WebSocket is also why automatic failover works — the panel can see in real time which devices have live sockets and route around a dropped phone without waiting for a TCP timeout on your side.

Hop 5 — device to the target

The Android device opens a regular outbound TCP socket to the target host and port specified in the connect frame. The key point: the TCP connection originates from the device's mobile cellular interface, so the target site sees a genuine mobile carrier IP assigned through carrier-grade NAT. That IP is shared by many real subscribers on the same network, which is why it carries a high trust score.

Optional features that apply at this hop:

• TCP/IP fingerprint spoofing — the device can adjust TCP window sizes, TTL and other stack parameters to mimic a target OS fingerprint. See TCP fingerprint spoofing.
• Upstream forwarding — instead of using the device's own SIM IP, the device can forward traffic through an external residential or backconnect upstream provider you supply. Covered in upstream residential forwarding.
• Geo and carrier targeting — the device chosen at hop 3 already carries a specific country, city and carrier, controlled by the username modifiers you append (-country-tr, a city tag, a carrier name). See geo-targeting.

The response from the target travels back along exactly the same chain in reverse: device socket → WebSocket frame → edge server → Cloudflare → client.

What you can and cannot control

The total round-trip for a request through a Nodetonet proxy is the sum of four network legs: client → Cloudflare + Cloudflare → edge + edge → device + device → target. Removing any leg is not possible — each serves a real purpose. But you control three of the four:

• Client → Cloudflare: not controllable — Cloudflare anycast always routes you to the nearest PoP automatically.
• Cloudflare → edge: controlled by your edge server choice. Keep this short by picking the edge closest to where your scraper or automation runs.
• Edge → device: controlled indirectly by which device pool you assign to the token group; devices on the same LAN as the edge obviously shorten this leg, but in most deployments the device is a phone anywhere in the world.
• Device → target: controlled by your geo-targeting choice. Pick devices in the country and carrier that makes sense for the target you're hitting.

If you want to inspect what IPs and latencies your proxies are actually delivering, use our free proxy checker or the What is my IP tool routed through the proxy.

Protocols: HTTP, HTTPS and SOCKS5

The same physical chain above carries all three protocols Nodetonet supports. The difference is in what socks5Server does at hop 3:

• HTTP CONNECT — the client sends a CONNECT tunnel request; the server establishes a TCP relay to the target host.
• HTTPS — identical to HTTP CONNECT for the proxy, but TLS from the client terminates at the Cloudflare edge and the inner TLS from device to target is end-to-end encrypted.
• SOCKS5 — the client negotiates the SOCKS5 handshake (optionally with username/password auth), then the server opens a TCP connection to the requested destination. SOCKS5 supports any TCP traffic, not just HTTP, so it works for database clients, game bots, custom binary protocols and more. See SOCKS5 with authentication.

The edge-panel split and why it matters

Nodetonet separates two layers that many single-server proxy systems run together: the control plane (the panel — billing, configuration, dashboard) and the data plane (the edge server — actual proxy traffic). The edge server pulls configuration from the panel and then runs autonomously. This split is what makes it possible to handle high concurrency on the edge without the panel becoming a bottleneck, and why a panel restart does not interrupt active tunnels.

It also means you can run multiple edge servers in different regions and assign different proxies to each — an architecture that is impossible with a monolithic setup. Interested in running your own edge node or setting up the full platform? Start from the pillar guide or explore the features overview.

What to read next

• Choosing the right edge server — which PoP to pick for your workload.
• Monitoring your tunnel health — how to keep tabs on the chain above.
• Sticky sessions explained — pinning a session to a device across requests.
• Automatic failover for mobile proxies — what happens when a device drops mid-session.
• Create a free account — see the full data path in action in minutes.