Forwarding a residential provider behind Nodetonet — Smartproxy, Bright Data, IPRoyal, Oxylabs

Most Nodetonet users start with a phone in their pocket as the exit device, giving them a real mobile carrier IP that anti-bot systems barely touch. But sometimes you need breadth that a phone fleet alone cannot deliver — hundreds of geographic locations, desktop residential IP ranges, or temporary scale-up for a short campaign. That is when you point a Nodetonet proxy at an external residential provider as an upstream.

TL;DR: configure Nodetonet as the front door your clients connect to; configure Smartproxy, Bright Data, IPRoyal or Oxylabs as the back end. You get the upstream's exit IPs while Nodetonet handles auth, per-client billing, domain allow/deny, sticky sessions, audit logs and TCP-fingerprint spoofing — all in one panel.

Why put Nodetonet in front of a residential pool?

If your scraper already speaks directly to Smartproxy, what does adding Nodetonet buy you? Three things that matter at scale:

• Credential isolation. Your upstream credentials never touch scraper code, worker config files, or customer accounts. Only Nodetonet holds the real upstream string. Rotate, swap providers, or renegotiate a contract without touching a single deployed script.
• Billing and resale layer. You set your own per-GB or per-second price on top of the residential cost. Each customer sees a single Nodetonet credential, a single bill, and a single support contact — yours. White-label resale via WISECP extends this to a fully branded portal.
• Unified access controls. IP allowlists, domain restrictions, per-client quota limits, expiry dates and thread caps all work the same whether the backend is a phone or a residential pool. Your customers get a consistent surface regardless of what is behind it.

You also pick up TCP fingerprint spoofing and SNI routing on the way out — so even when the exit IP is a residential address, the TLS handshake looks like a real browser rather than a headless script.

Supported upstream providers — at a glance

Nodetonet accepts any upstream that exposes a standard host:port:user:pass endpoint over HTTP or SOCKS5. The four major residential providers all do:

For a deeper comparison of what each provider is best at see Nodetonet vs Bright Data, vs Smartproxy, vs Oxylabs and vs IPRoyal.

Setting up the upstream connection string

When you create or edit a rotating proxy in the panel, the Upstream Proxy field takes a single colon-delimited line in this format:

host:port:username:password

Paste in the string for your provider and hit Create. The platform validates the format immediately but does not attempt a live connection until the first client request arrives — so a typo in the password will only surface when traffic starts flowing. Always send one test request right after setup to confirm the credentials are correct before handing the proxy to a customer.

Full examples for each provider (substitute your real credentials):

# Smartproxy — rotating residential
gate.smartproxy.com:7000:sp12345:mypass

# Bright Data — residential zone
brd.superproxy.io:22225:brd-customer-hl_abc123-zone-residential:pass

# IPRoyal — residential
geo.iproyal.com:12321:user:pass_country-us

# Oxylabs — residential rotating
pr.oxylabs.io:7777:customer-USR1-cc-de:pass

Username modifiers pass through verbatim

Every residential provider uses the username field for targeting — country, city, session ID, sticky duration. Nodetonet forwards the username field to the upstream exactly as supplied. There is no stripping, rewriting or URL-encoding on our side.

If you want German IPs from Smartproxy with a pinned sticky session:

gate.smartproxy.com:7000:sp12345-country-de-session-myabc123:mypass

If you want US residential rotating from Oxylabs:

pr.oxylabs.io:7777:customer-USR1-cc-us:pass

The second colon in the connection string is the username/password delimiter; everything between the first and second colons is treated as the username and sent verbatim upstream. See upstream username modifiers in depth for how each provider's syntax works.

Sticky sessions across both layers

When your client appends a sticky session suffix to their Nodetonet username — for example user-session-abc123 — Nodetonet maps that token to a deterministic upstream session. The same token always selects the same upstream session ID, which means the same exit IP for the configured TTL.

This two-layer stickiness is more reliable than relying on the upstream alone: if a Nodetonet edge node restarts, the session map is rebuilt from the hot cache and the scraper keeps its IP. If the upstream session expires before Nodetonet's TTL, a new upstream session is negotiated transparently using the same mapping key, so the client code never needs to rotate manually. See sticky sessions across the chain for the full TTL and cache-behaviour details.

Sticky over a chained upstream is the most reliable way to hold a residential IP across a long-running login or checkout flow. The upstream sees one session ID from Nodetonet; your client sees one pinned address for as long as the TTL holds.

Per-client controls — billing, quotas and access

Upstream forwarding does not change how proxy clients work. You can still create a separate client credential per customer and attach to it:

• Bandwidth quota — cut off a client at a specific GB total, then recharge manually or automatically.
• Thread limit — cap the maximum concurrent connections so one heavy user cannot saturate the upstream port.
• Expiry date — issue a time-limited credential that stops working after a trial or subscription period ends.
• IP allowlist — restrict which source IPs may authenticate, so credentials leaked in client code cannot be abused from elsewhere.
• Domain allowlist or denylist — control which target domains a client is permitted to reach through the upstream. See domain restrictions.

Nodetonet bills your account for edge bandwidth and proxy-seconds at the same rate as any other proxy. The upstream provider bills you separately for the traffic you route through them. There is no markup from Nodetonet on upstream bytes — what you pay the upstream is what you pay the upstream.

What you actually pay — cost model explained

The math of the two-tier model is straightforward. Nodetonet charges a small edge fee per gigabyte or per second (check your plan). The residential provider charges their own per-GB rate. For most setups the total comes out close to the cost of using the residential provider directly, because Nodetonet's edge fee is small relative to residential per-GB pricing.

Where it clearly wins for resellers: you charge your customers a bundled rate that covers both the upstream cost and the Nodetonet edge fee, then pocket the margin. Each customer gets one credential and one invoice without ever knowing which upstream provider is behind the service. This is the foundation of the white-label reseller model.

Debugging common problems

The overwhelming majority of upstream forwarding issues come down to three root causes:

1. Upstream auth failure (407). Every request through the proxy returns a 407 or connection reset, but a direct test from your own machine with the same credentials works. Check whether the upstream provider has IP-whitelisted your machine — Nodetonet's edge server IP may not be on the allowed list. Add the edge's static IP to the upstream IP allowlist, or switch the upstream account to username/password auth (no IP restriction). Also check for special characters in the password — a @ or : that got URL-encoded somewhere in copy-paste.
2. Wrong port for the protocol. Most providers serve HTTP and SOCKS5 on different ports, and sticky vs rotating may be on different ports too. Double-check the provider's documentation for the exact port matching your protocol. Use our proxy checker to confirm the upstream is reachable from the edge before troubleshooting further.
3. Username modifier syntax mismatch. Each provider has its own delimiter style — Smartproxy uses -country-XX, IPRoyal uses _country-XX, Oxylabs uses -cc-XX. A delimiter from the wrong provider is silently ignored by most endpoints, and you get an unfiltered exit IP instead of the country you wanted.

For a step-by-step diagnostic flow including how to read the error logs on the edge see debugging upstream auth failures.

When NOT to use upstream forwarding

Upstream forwarding adds a hop and adds cost. It is the right choice when you need the upstream's exit IPs and geo breadth combined with Nodetonet's control layer. It is the wrong choice when:

• You already own the devices and just want mobile proxies from your own SIM fleet — no upstream needed.
• You want a proxy that only forwards with no paired device at all — see upstream-only proxies.
• The target is lightly protected and a datacenter IP would do — the per-GB residential cost is wasted for easy targets.

Get started

Ready to chain a residential pool? Create a Nodetonet account, open /proxies, create a rotating proxy and paste your upstream string into the field. For next steps on controlling what each of your customers can do with it, read proxy clients and per-customer auth. And if you're new to the platform, the quickstart guide gives you the full picture in under ten minutes.