By default every Nodetonet proxy answers on a subdomain we choose — something like sub42.nodetonet.com. That works fine for personal use, but the moment you are reselling or white-labelling to customers you need your domain on the connection string, not ours. Customers should see proxy.acme.com, not a hostname that advertises a third-party platform.
Custom domain support solves this in roughly one minute of configuration. You add the domain in the panel, create one DNS record, and from that point every proxy or HTTP tunnel under that domain answers on your brand with a real, auto-renewing SSL certificate. No long migration, no nameserver transfer, no waiting on registrar tickets. This guide walks through every step and explains when the CNAME path is the right choice and when you should consider handing Nodetonet full DNS authority instead.
Why a custom domain matters for resellers
If you are running a white-label reseller operation, every touchpoint your customer sees should be yours. A connection string that contains nodetonet.com raises questions — your customer may search for the upstream provider, compare prices directly, or lose confidence in your service. A custom domain closes that gap: same mobile proxy infrastructure, same edge servers, same prepaid billing model — but entirely on your brand.
The same logic applies to internal tooling. A team proxy endpoint at proxy.yourcompany.com is easier to remember, easier to audit in logs, and easier to rotate without updating every client that has a hostname hardcoded.
Step 1 — Add the domain in the panel
Go to the /domains section in your panel and click + Add domain. Enter the apex or subdomain you want to use — proxy.acme.com, tunnel.example.io, or any hostname you control. The panel saves it with a status of Pending verification and immediately shows you the single CNAME target you need to point at.
That target is always cname.nodetonet.com — one target for every domain, every customer, forever. There is no per-customer subdomain and no per-domain special host to remember. Copy it once and you are done.
Step 2 — Create the CNAME at your DNS provider
Log in to wherever your DNS lives — Cloudflare, AWS Route 53, Namecheap, Google Domains, Gandi, or any other provider — and add one record:
proxy.acme.com. CNAME cname.nodetonet.com.Two provider-specific caveats worth knowing:
- Cloudflare users: set the record to DNS-only (grey cloud icon), not Proxied (orange cloud). When Cloudflare proxies the record it terminates TLS itself, which prevents Nodetonet from completing the ACME HTTP-01 challenge and issuing the certificate.
- Apex domains: classical DNS forbids a CNAME at the zone apex (
acme.comwith no subdomain). Use a subdomain such asproxy.acme.com, or check whether your provider supports an "ALIAS" or "ANAME" record type that flattens a CNAME at the apex.
Step 3 — Wait about 30 seconds
The panel polls DNS every few seconds. The moment your CNAME resolves to cname.nodetonet.com, two things happen automatically and in sequence:
- Domain verification flips to Verified. The CNAME record itself proves you control the hostname — no TXT record, no HTML file upload, no token paste required.
- A Let's Encrypt certificate is issued. Nodetonet runs an HTTP-01 ACME challenge, terminated at the edge. The certificate is typically live within 10–20 seconds. Once it lands, the panel displays the subject alternative names (SANs) and the expiry date.
From this point on, any proxy you create under your account can be assigned to your custom domain instead of the default sub*.nodetonet.com.
Step 4 — Assign proxies to your domain
Create a new proxy and select your verified domain from the dropdown, or edit an existing proxy and reassign it. The connection string immediately updates to your hostname:
https://u8x2:p7q1@proxy.acme.com:48888The underlying infrastructure is unchanged — same device pool, same rotating or sticky-session logic, same geo-targeting username modifiers, same usage accounting. Only the hostname your customer sees is different.
You can assign many proxies to one domain. Each proxy gets a distinct port on that hostname, so the same proxy.acme.com can serve dozens of concurrent endpoints. The certificate's SAN list covers the bare hostname and Nodetonet handles port routing at the edge transparently.
Step 5 — Certificate renewal is fully automatic
Let's Encrypt certificates have a 90-day lifetime. Nodetonet schedules renewal at day 60 and silently swaps in the new certificate at the edge — no proxy restart, no downtime, no action required from you. See Let's Encrypt auto-renewal for what the renewal flow looks like and what happens when a renewal fails.
If renewal fails — for example because you removed the CNAME or pointed it elsewhere — the panel surfaces a banner with the exact reason, and your account contact address receives one notification email. Fix the DNS record and the next renewal cycle completes automatically.
CNAME vs full DNS delegation — when to use each
The CNAME approach is the lightest possible integration: one record, you keep full control of the rest of your DNS zone. That is the right starting point for almost every operator. However, it has one structural limit: you can only delegate the name to Nodetonet, not the zone. Nodetonet cannot add, rotate or delete sibling records on your behalf.
| Scenario | CNAME approach | Authoritative NS delegation |
|---|---|---|
| One or a handful of proxy hostnames | Ideal — one record per hostname | Overkill |
| Dozens of subdomains for dozens of customers | Tedious — one CNAME per subdomain | Ideal — wildcard records, no per-customer work |
| Keeping your existing DNS provider | Supported — no migration needed | Requires NS record change at registrar |
Wildcard certificate across *.proxy.acme.com |
Via wildcard cert guide | Fully automated with DNS-01 challenge |
| Zone-level TXT / MX / SPF records | You manage them yourself | Nodetonet manages them on your behalf |
If you are at the point where CNAME management is a bottleneck — issuing subdomains for many customers without adding a DNS record per customer — read Authoritative DNS on our nameservers.
Custom domains and per-client controls
A custom domain does not change any of the access controls you already have. Each proxy sitting behind proxy.acme.com still supports the full set of per-client controls: username/password authentication, IP allowlists and denylists, domain restrictions, bandwidth quotas, thread limits, and expiry dates. Your reseller customers connect through your domain and see only what you give them; the Nodetonet panel stays invisible to them entirely.
What's next
- Authoritative DNS on our nameservers — delegate an entire zone for zero per-customer DNS work.
- Wildcard SSL certificates — cover
*.proxy.acme.comin a single certificate. - Let's Encrypt auto-renewal — what to watch if a renewal cycle fails.
- Proxy clients and per-customer auth — issue isolated credentials for each reseller customer.
- Reseller and white-label features — the full picture of Nodetonet's reseller stack.
- Create a free account and add your first custom domain in minutes.