Migrating from Localtonet — concept map, pricing, and a script port in 20 minutes

If you are coming from Localtonet, almost every concept you already know transfers directly to Nodetonet. The model is the same: pair a device, give each tunnel a name and subdomain, authenticate with a token. What changes is the feature ceiling and — crucially — the billing model. This guide maps every Localtonet concept to its Nodetonet equivalent, explains the pricing shift, and walks you through porting a real automation script. Most teams complete the migration in under 20 minutes of active work.

TL;DR: rename three things, swap your hostname, and you are live — but read the pricing section first because the switch from monthly subscription to prepaid credit changes how you should think about keeping proxies running.

Why teams switch from Localtonet

Localtonet is a solid HTTP-tunnel tool. Teams outgrow it when they need any of the following, none of which Localtonet provides:

• Mobile proxy output — turning an Android phone's cellular IP into a rotating or sticky proxy that websites trust at the carrier level.
• Geo and carrier targeting — requesting a specific country, city or carrier (Turkcell, Vodafone, Turk Telekom) from a single endpoint via username modifiers.
• SOCKS5 support — forwarding raw TCP for non-web tools, game clients and custom protocols, not just HTTP/HTTPS.
• Per-client sub-credentials — issue separate usernames and passwords with their own quotas, thread limits and IP allow-lists to each customer or team member, without ever sharing your root credentials.
• Reseller / white-label — WISECP-connected billing so you can sell proxy access to end customers under your own brand.
• Upstream residential forwarding — chain your tunnel to an external residential pool for coverage on targets that need fresh residential IPs.

If you only need basic HTTP tunnels and those features are irrelevant today, Localtonet may still serve you. But the migration is low-risk and free to try, so most teams do it anyway to avoid hitting a wall later.

The concept map

Every Localtonet term has a direct Nodetonet counterpart. The table below shows the mapping plus any meaningful behavioural differences:

The pricing model — read this before you migrate

Localtonet bills on a monthly subscription: you pick a tier and pay whether or not you use it. Nodetonet uses prepaid credit: you load a balance, each running proxy burns it down at a per-day rate, and when the balance hits zero the proxies pause (your data is preserved — resume after topping up). If you do not run any proxies, you pay nothing.

Practical implications:

• Bursty workloads win big. Running 20 proxies for 3 days during a campaign costs 60 proxy-days — not a full month at the "20-proxy plan" rate.
• Forgetting to cancel costs nothing. If you stop using the platform for a month, you owe nothing. With Localtonet you would have been billed twice.
• Idle proxies are cheap, not free. A proxy left running but not receiving traffic still burns a small daily credit. Delete or pause proxies you are not actively using.
• Heavy steady users should model the cost. If you run many proxies 24/7 every month, model the daily rate against your current Localtonet tier before switching. For most users bursty usage means prepaid wins.

Step-by-step migration

The full migration — assuming you have an existing Localtonet setup — looks like this:

1. Create your Nodetonet account and verify your email. See the getting-started walkthrough for a full signup-to-live-proxy run-through.
2. Add a small credit balance (even a minimal top-up activates the platform fully).
3. Pair each device. Install the Nodetonet Android agent on each phone, pair it with a new token. You do not need to migrate all devices on day one — your old Localtonet tunnels keep running until you cancel there.
4. Recreate each tunnel as a Nodetonet proxy. Pick subdomain, protocol (HTTP or SOCKS5), and edge server. Leave the port on auto unless your downstream code requires a specific number.
5. Update your scripts — see the worked example below. The change is three string values.
6. Run both in parallel for a week if your risk tolerance is low. Once every endpoint is confirmed working, cancel your Localtonet subscription.

If you are managing a large number of proxies, the REST API lets you provision everything from a Python script rather than clicking through the panel.

Handling subdomains and hostnames

Localtonet gives you <sub>.localtonet.com; Nodetonet gives you <sub>.nodetonet.com. If your scripts have the hostname hardcoded in many places, a global find-and-replace is the fastest path.

If you want zero code changes in downstream scripts, point a CNAME from your own domain at our subdomain and we will issue a wildcard certificate — see bringing your own domain and wildcard SSL certificates. Once the CNAME is live, tun-37.acme.com works identically to sub42.nodetonet.com and every existing script keeps working unmodified.

Worked example — porting a Python scraper

This is what a typical Localtonet-based request looks like:

import requests

proxies = {
    "http":  "http://abc123-eu.localtonet.com:8080",
    "https": "http://abc123-eu.localtonet.com:8080",
}
r = requests.get("https://api.ipify.org", proxies=proxies)
print(r.text)

The same scraper on Nodetonet, with HTTP proxy auth:

import requests

# Credentials come from the Proxies page in the panel — copy directly.
USER = "u8x2"
PASS = "p7q1"
HOST = "sub42.nodetonet.com"
PORT = 48888

proxies = {
    "http":  f"http://{USER}:{PASS}@{HOST}:{PORT}",
    "https": f"http://{USER}:{PASS}@{HOST}:{PORT}",
}
r = requests.get("https://api.ipify.org", proxies=proxies)
print(r.text)

That is the entire diff: three string values changed and you have switched providers. If you prefer SOCKS5 — for example to route non-HTTP traffic — swap the scheme to socks5h:// using the same host, port and credentials:

proxies = {
    "http":  f"socks5h://{USER}:{PASS}@{HOST}:{PORT}",
    "https": f"socks5h://{USER}:{PASS}@{HOST}:{PORT}",
}

If you manage many proxies programmatically, read credentials from the REST API instead of hardcoding them. One call returns every proxy and every credential set — your scripts become independent of the source of truth and you can rotate credentials without touching code. See your first REST API call and programmatic tunnel provisioning from Python.

Adding mobile proxy output (optional upgrade)

Once your tunnels are migrated, you can upgrade any proxy to expose the phone's real cellular IP rather than just forwarding to localhost. This turns the device into a genuine mobile proxy — outbound requests exit from a carrier IP shared with thousands of real subscribers, which is the hardest fingerprint for anti-bot systems to block.

Two modes are available on the same proxy endpoint:

• Rotating — the carrier assigns a fresh IP on each request or on a timer. Best for web scraping, SERP monitoring and ad verification at scale.
• Sticky — one IP is pinned for an entire session so logins and checkout flows stay on the same identity. Enable it by appending -session-XXXX to the proxy username.

You can also group devices into token groups for round-robin and least-connection selection with automatic failover — effectively a self-managed rotating pool. See setting up a rotating mobile proxy from scratch for a full walkthrough.

Features Nodetonet has that Localtonet does not

• Geo and carrier targeting. Append a country code, city tag or carrier name to the proxy username to route through a specific location without changing endpoints. See geo-targeting for the full syntax.
• Per-customer sub-credentials. Create isolated proxy clients, each with its own username, password, quota, expiry date, thread limit and IP allow-list. You can resell access without ever sharing your root credentials. See proxy clients and per-customer auth.
• Upstream residential forwarding. Chain Bright Data, Smartproxy, IPRoyal or any SOCKS5-compatible pool behind your Nodetonet endpoint. Your scripts keep the same address while you swap upstream providers silently. See upstream residential forwarding.
• TCP/IP fingerprint spoofing. Mask the proxy's network stack fingerprint so tools like JA3 or p0f read a different OS or browser than the host machine. See TCP fingerprint spoofing.
• VPN alongside proxies. Nodetonet includes an integrated VPN — useful when you need full-device routing rather than per-request proxy control. See the VPN feature and VPN vs proxy for when to use which.
• HTTP tunnels via Windows agent. A lightweight .exe agent on Windows hosts HTTP tunnels with the same panel, token and billing as your mobile proxies. See HTTP tunnels.

Comparing Nodetonet with Localtonet at a glance

What to do if you hit a wall mid-migration

Most migration issues fall into one of three categories: credential format (the user:pass@host:port scheme is new if you came from unauthenticated Localtonet tunnels), firewall rules blocking the new port, or a proxy client needing the HTTPS certificate re-trusted after the hostname change.

If you get stuck, the support flow guide walks through how to reach us — email support@nodetonet.com, join the Discord at discord.gg/nodetonet, or follow x.com/nodetonet for status updates. You can also use the proxy checker tool to verify a proxy is live before pointing scripts at it.

What to read next

• The getting-started walkthrough — signup to live proxy in under five minutes.
• Provisioning tunnels from Python — the REST-API equivalent of the worked example above.
• Set up a rotating mobile proxy from scratch — the optional upgrade path once you are migrated.
• Understanding your bills — model the prepaid credit burn rate before committing to a large fleet.
• VPN vs proxy — understand which tool to reach for on each type of task.