Proxy clients — give each customer their own login on one tunnel

You have a rotating proxy backed by a pool of mobile devices, and now you need to hand access to more than one person. The obvious move — sharing the same username and password — is also the worst one. The moment a credential leaks, everyone is exposed and your audit log can no longer tell you who did what. The proxy-client primitive exists precisely to solve this problem.

A proxy client is a scoped credential pair that sits in front of a single tunnel. Each client has its own username, password, monthly bandwidth quota, thread cap, IP allow-list, and optional expiry date. You can stack many clients on the same tunnel. Your end users never need a Nodetonet account — they just receive a connection string. They cannot see your dashboard, cannot inspect the underlying rotating proxy pool, and cannot interfere with each other.

The mental model

Think of one tunnel as a building and proxy clients as keycards. Every keycard opens the same door, but the building's access log records which card swiped, and you can invalidate a single card without changing the lock or disturbing anyone else.

tunnel: sub42.nodetonet.com:30000  (rotating pool from mobile devices)
  ├── client: customer-a / pw1   quota 100 GB  · 50 threads
  ├── client: customer-b / pw2   quota  20 GB  · 10 threads
  └── client: customer-c / pw3   quota 500 GB  · 200 threads · IP allow 1.2.3.0/24

All three customers point their tool at the same host and port. The edge layer reads the presented username, locates the matching client record, enforces that client's rules (quota remaining, thread count, IP allow-list), and forwards through the shared device pool. A customer who exhausts their quota is stopped; the others are unaffected.

Creating a proxy client

Open any proxy detail page in the panel and click the Proxy Clients tab, then + New client. Fill in:

• Username and password — any values you choose; they never collide with Nodetonet account credentials.
• Monthly GB quota — leave blank for unlimited, or enter a cap. Usage is tracked in real time.
• Thread limit — maximum concurrent connections this client may hold open simultaneously.
• IP allow-list (CIDR) — optional; if set, only requests from those source IPs are forwarded.
• Auto-expire date — optional; the client is disabled automatically at midnight on that date.

Save the form and you receive a connection string ready to hand to your customer:

http://customer-a:pw1@sub42.nodetonet.com:30000

That string works identically in curl, Python requests, Scrapy, Puppeteer, Playwright, or any tool that accepts an HTTP or SOCKS5 proxy. Your customer never logs in anywhere; they paste the string and go.

What per-client controls actually buy you

Bandwidth quota

A quota is a hard ceiling on the gigabytes a client may transfer in a calendar month. Nodetonet tracks usage in real time — the live dashboard and audit log both show bytes consumed per client. Once a client's quota is exhausted, further requests are refused at the edge until the next month or until you manually reset the counter. You can adjust the quota on a live client at any time without restarting anything.

Thread (concurrency) limits

A thread limit caps how many simultaneous TCP connections a client may hold through the tunnel. This protects your device pool from a runaway job: if one customer's scraper goes haywire and opens hundreds of connections, it hits only its own cap and cannot starve other clients. See thread limits per client for the enforcement mechanics.

IP allow-list

When a client has an allow-list, the edge checks the source IP of every incoming connection before even validating the password. A credential that leaks to a stranger is useless if that stranger's IP is not on the list. List entries accept single IPs and CIDR ranges. This pairs well with tunnel-level IP and domain restrictions — the client rule is an additional gate on top of any tunnel-level rules.

Auto-expiry

Set an expiry date and the client disables itself automatically — no cron job, no manual cleanup. This is the right pattern for trial access, short-term contractor projects, or any time-boxed engagement. See time-limited proxy clients for the full workflow.

Use cases

Reselling proxy access

If you run a pool of mobile devices and want to sell bandwidth to end users, proxy clients are the billing unit. Issue one client per customer, set their monthly GB cap, charge accordingly, and read the audit log to see exactly who consumed what. Your customers never see the Nodetonet panel. This is also the foundation of white-label reselling — pair it with WISECP for fully branded customer management. Because billing is prepaid credit rather than a monthly subscription, you carry no idle cost when a client is quiet.

Multi-team or multi-environment scraping

Internal teams that share a proxy pool still benefit from per-client separation. A staging credential and a production credential on the same tunnel mean that a load spike in staging cannot consume production's thread budget. Per-environment credentials also make the audit log instantly filterable by workload.

Geofenced or source-IP-restricted access

Allow-list a client to a specific office CIDR. Even if the password escapes into a public Pastebin, no outsider can use it. This is the pattern for giving a client access to a rotating or sticky pool without trusting them to keep the credential secret.

Contractor or trial accounts

Create a client with a small quota and a 7-day expiry for a trial user or a contractor on a fixed engagement. When the date passes, the client silently disables. Nothing to revoke, nothing to clean up.

Per-client controls vs tunnel-level controls — comparison

What the audit log tells you

Every row in the audit log carries the clientId of the proxy client that authenticated the request. That means you can filter by client to produce per-customer usage reports, identify which client is approaching its quota, or investigate a spike. The most actionable view is bytes per client per day — it shows who is nearing their cap and who is under-using and might be a churn risk.

Even when you have only one customer today, create a proxy client from the start. The overhead is zero and you preserve the option to add a second customer, rotate the first customer's credentials, or split environments later — without ever touching the tunnel itself.

Limits to plan for

Proxy clients do not change how the underlying tunnel or device pool works. A few things worth knowing upfront:

• Device selection is tunnel-level, not client-level. If your tunnel rotates through a pool of phones, every client gets the rotating pool. You cannot pin one client to a specific device while another rotates. For full device isolation, spin up a separate proxy for that client.
• Egress IPs are shared. If one customer causes a device to be IP-banned by a target site, the next customer who happens to exit through that same device will encounter the same ban. Token groups with round-robin selection spread the risk; if you need hard separation, separate tunnels are the answer.
• Tunnel-level domain restrictions are always enforced. If you block a domain at the tunnel level, no client can reach it regardless of their own settings. Per-client controls are additive restrictions — they cannot loosen what the tunnel already blocks.
• SOCKS5 and HTTP both work. The connection string protocol (http:// or socks5://) is set by the client, not by the proxy-client record. Both protocols support username/password authentication, so you can hand out either type of connection string for the same proxy client.

Sticky sessions with proxy clients

A proxy client is fully compatible with sticky sessions. Your customer appends -session-XXXX to the username you gave them — for example customer-a-session-checkout1 — and the tunnel pins that session to one egress device for the session TTL. The quota and thread limits still apply; the sticky pinning is enforced within those constraints. See sticky sessions explained for the full syntax and timing rules.

Protocol: HTTP, HTTPS and SOCKS5

The same proxy client credential works for both HTTP/HTTPS and SOCKS5. Most scrapers and browsers use HTTP; SOCKS5 is the better choice for raw TCP applications, game clients or anything that needs to forward non-HTTP traffic. Our guide on HTTP vs SOCKS5 covers when each protocol is the right pick and how to configure them.

Get started

Proxy clients are available on every rotating proxy in the panel. If you have not set up a rotating proxy yet, the quickstart in rotating mobile proxy from scratch walks through pairing phones, creating a token group, and launching a tunnel — after which you can add proxy clients in the same Proxy Clients tab. Ready to try it? Create an account and add your first client in minutes.