Do you support SOCKS5 with username/password auth?

Yes — SOCKS5 with username/password auth is fully supported, along with an optional IP whitelist. HTTP and HTTPS use the same auth system. See the detailed walkthrough in our SOCKS5 with authentication guide.

Can one device pool serve HTTP and SOCKS5 simultaneously?

Yes. The same paired Android device pool backs all three protocols. You just create separate proxy entries with the protocol each tool needs. They can even share a sticky session token for correlated exit IPs across protocol types.

Does using an HTTPS proxy mean you can read my traffic?

No. HTTPS uses CONNECT tunnelling — TLS is established end-to-end between your client and the destination server. The proxy opens a TCP tunnel and forwards encrypted bytes without decrypting them. For more on this see our post on HTTPS proxies and SNI routing.

What is the difference between HTTP and SOCKS5 proxies?

HTTP proxies work at the application layer and understand HTTP/HTTPS only. SOCKS5 works at the TCP/UDP transport layer and forwards any protocol — web or non-web. For most web scraping, HTTP is simpler; for custom clients, game tools or anything that is not plain HTTP, SOCKS5 is the right choice. Full breakdown in our HTTP vs SOCKS5 guide.

Do sticky sessions work with SOCKS5?

Yes. Sticky sessions are managed at the token/device-pool level, so they work identically across HTTP, HTTPS and SOCKS5. Append -session-XXXX to your proxy username and all connections sharing that suffix pin to the same exit device for the session TTL.

Can I restrict which websites a client can access through their proxy?

Yes. Per-client domain allow and deny lists let you restrict which destinations a credential can reach. Combined with an IP whitelist and bandwidth quota, you get full control over how each client uses the proxy — useful for resellers or teams running shared pools. See domain restrictions for configuration details.

Is there a free trial or do I need a subscription?

Nodetonet uses prepaid credit with no monthly subscription — you load credit and spend it as you go. Idle proxies cost nothing. Create a free account to explore the panel before loading any credit.

SOCKS5 & HTTP proxies — authenticated, on real mobile IPs

Most scraping libraries default to HTTP. Custom game clients speak SOCKS5. Browser automation stacks want HTTPS CONNECT. When the protocol is non-negotiable, the proxy layer should bend — not your code. Nodetonet serves HTTP, HTTPS and SOCKS5 from the same real 4G/5G device pool, so you choose what your tool already knows, and the mobile IP underneath never changes.

TL;DR: pick HTTP for simplicity, HTTPS for end-to-end TLS, SOCKS5 for anything non-web — all backed by real carrier IPs with username/password auth, IP whitelists, domain rules, and per-client bandwidth quotas.

HTTP, HTTPS and SOCKS5 — what each one actually does

These three protocols are often lumped together but they work at different layers and carry different trust assumptions:

HTTP proxy

The oldest and most widely supported mode. Your client sends a plain GET http://example.com/ to the proxy instead of to the server. The proxy forwards it, and returns the response. Nearly every HTTP library, scraping framework and browser supports this with zero configuration. The trade-off is that the proxy sees the URL, headers and body of every request — fine for public web scraping, not ideal for sessions that carry cookies or credentials.

HTTPS proxy (CONNECT tunnelling)

Your client sends CONNECT example.com:443 HTTP/1.1 and the proxy opens a raw TCP tunnel. TLS handshakes and all subsequent bytes travel encrypted — the proxy never sees inside the stream. This is the right mode for any authenticated session, payment flow, or request carrying sensitive headers. See our blog post on HTTPS proxies and SNI routing for deeper detail on how that tunnel negotiation works.

SOCKS5 proxy

SOCKS5 operates below the application layer: it forwards raw TCP (and optionally UDP) bytes without caring what protocol lives inside. That means it works for any TCP-based application — not just web browsers but also database clients, SSH tunnels, game clients, BitTorrent peers, or a custom binary protocol. SOCKS5 also supports username/password authentication directly in the handshake. For a thorough introduction see our SOCKS5 proxy glossary entry and the practical guide on SOCKS5 with authentication.

Protocol comparison at a glance

Protocol	Works with	Proxy sees content?	UDP support	Best for
HTTP	Any HTTP library, browser, curl	Yes (plain text)	No	Simple web scraping, public APIs
HTTPS (CONNECT)	Modern browsers, Playwright, Puppeteer	No (TLS tunnel)	No	Authenticated sessions, payments, cookies
SOCKS5	Python PySocks, curl --socks5, any raw TCP app	No	Yes	Non-web apps, game tools, SSH, custom clients

Still unsure which fits your stack? The HTTP vs SOCKS5 decision guide walks through the trade-offs with concrete examples. If your tool accepts both, SOCKS5 is usually the more future-proof choice — it handles every protocol HTTP can, plus everything HTTP cannot.

Authentication and access control

Every proxy you create on Nodetonet is locked down in layers. You decide which combination to use:

Username / password — standard proxy auth understood natively by virtually every client library. Set per client, so different teams or customers get isolated credentials. Read more about per-customer auth.
IP whitelist — only listed source IP addresses can use the proxy, regardless of credentials. Ideal for a scraper server with a static egress IP. Your customer can update the whitelist remotely through a per-order link or the REST API, with no panel login required. See also IP allow/deny lists.
Domain allow / deny lists — restrict which destinations a given client can reach. Useful for resellers who want to prevent misuse or limit a client to specific target sites. Details at domain restrictions.
Bandwidth quotas — set a byte cap per client. Once exhausted the client is refused until you reset or the expiry date passes. Pair with thread limits to cap concurrency too. Full docs at quota limits per client.
Expiry date — grant a proxy for a fixed time window (useful for trials or short-term API customers). See time-limited proxy clients.

These controls are orthogonal: you can combine an IP whitelist with a quota and a domain deny-list on the same client credential. They apply equally across HTTP, HTTPS and SOCKS5.

Real mobile IPs underneath every protocol

Protocol choice does not change the exit IP. Whatever you pick, your traffic leaves from a real 4G/5G carrier IP assigned to one of the paired Android devices in the pool. Carrier-grade NAT (CGNAT) means that IP is shared by many genuine subscribers at the same moment — the exact property that makes mobile IPs the hardest to block. Compare this to a datacenter proxy whose /24 subnet is routinely listed in every block list, or a residential proxy pool that anti-fraud vendors increasingly fingerprint through re-use patterns.

Because all three protocols share the same device pool, you can run a SOCKS5 connection and an HTTP connection to the same exit device for perfectly correlated fingerprints — useful when one part of a workflow is browser-based and another is a custom binary client.

Rotating and sticky modes across all protocols

IP rotation works at the token / device pool level, not the protocol level — which means rotating and sticky sessions work identically whether you are on HTTP or SOCKS5:

Rotating (default) — a different device (and therefore a different carrier IP) is selected for each new connection. Ideal for bulk scraping, SERP monitoring or any stateless request. See rotating proxies for pool configuration options.
Sticky session — append -session-XXXX to your proxy username and all connections sharing that token are pinned to the same device for the duration of the session TTL. Essential for login flows, shopping carts, or any multi-step sequence that expects one IP throughout. Learn more at sticky sessions explained.

For upstream chaining — where Nodetonet forwards your request through an external residential or ISP provider before hitting the target — both modes also apply. See upstream residential forwarding.

Geo-targeting and carrier selection

Your exit IP carries a real location and carrier. To steer it, add modifiers to your proxy username — no endpoint change needed:

-country-tr — exit through a Turkish SIM
-city-istanbul — pin to Istanbul
-carrier-turkcell — request a Turkcell SIM specifically

You can combine modifiers (e.g. -country-tr-city-istanbul-carrier-vodafone). Availability follows the live device fleet. Full modifier syntax is documented on the geo-targeting feature page and in the username modifiers blog post.

TCP/IP fingerprint spoofing

Some advanced anti-bot systems go beyond IP reputation and inspect TCP/IP stack characteristics — window size, TTL, timestamp options — to distinguish datacenter traffic from real-device traffic. Nodetonet supports TCP/IP fingerprint spoofing at the edge layer, so the stack parameters observed by the target match what a genuine Android handset would send, not what a server would. Read the full details in TCP fingerprint spoofing.

How to get started

Create a free account and add prepaid credit — no subscription required.
Go to /proxies and create a new proxy, choosing HTTP, HTTPS or SOCKS5 as the protocol.
Add a client credential — set a username, password and optionally an IP whitelist or domain rules.
Point your tool at host:port with those credentials. Most libraries need one line: proxies = {"http": "http://user:pass@host:port"} for Python requests, or --proxy socks5://user:pass@host:port for curl.
Check proxy checker to confirm the exit IP and carrier before running at scale.

The setup guide walks through a full rotating-proxy configuration from scratch, including pairing your first Android device. The traffic routing explainer shows how each hop is handled under the hood.

Reselling HTTP and SOCKS5 proxies

If you want to offer these proxies to your own customers under your own brand, Nodetonet's reseller and white-label system lets you create per-customer credential sets with isolated quotas, expiry windows and domain rules — all backed by the same pool. Reseller billing integrates with WISECP for automated invoicing. Customers get credentials that work transparently over HTTP, HTTPS or SOCKS5 without knowing anything about the underlying infrastructure.

Summary

The proxy protocol should be a one-line decision, not a platform constraint. Nodetonet gives you HTTP for simplicity, HTTPS for TLS confidentiality, and SOCKS5 for any-application reach — all from real mobile carrier IPs, all with the same access-control stack. Sign up and run your first request in minutes, or explore the full features list to see what else is available in the same panel.