HTTPS proxies and SNI routing — how TLS lives on the edge

When you open the New Proxy form on Nodetonet and switch the protocol from HTTP to HTTPS, a chain of things happens behind the scenes: a TLS certificate is issued for your subdomain, the edge learns which tunnel to route encrypted traffic into, and your client gets a proxy it can talk to without any certificate warnings. This guide walks through every step — the certificate lifecycle, the SNI handshake, the precise moment TLS terminates, and exactly when to prefer HTTPS over plain HTTP or SOCKS5.

TL;DR: HTTPS-protocol proxies encrypt the proxy connection (client to edge) using a real Let's Encrypt certificate. The edge terminates TLS, then forwards plain HTTP proxy bytes down the secure agent channel to your paired mobile device. Target-site traffic is still encrypted end-to-end by HTTPS as normal — the proxy HTTPS layer only protects your auth credentials and the CONNECT metadata.

What "HTTPS proxy" actually means on the wire

It is easy to confuse the three places "HTTPS" can appear in a proxy setup. Here is the clearest breakdown:

The internal edge-to-device channel is always encrypted regardless of which protocol you pick — that is built into the Nodetonet agent. HTTPS-proxy mode adds TLS to the client-to-edge segment only. If your target sites are already served over HTTPS (which they almost certainly are), HTTPS-proxy mode does not change the end-to-end security of that traffic. What it does protect is the Proxy-Authorization header and the CONNECT host:port line that would otherwise travel in cleartext between your machine and the edge.

Certificate lifecycle: from form submit to first request

Every Nodetonet account is assigned a unique subdomain — for example sub42.nodetonet.com. The moment you create your first HTTPS proxy on that subdomain, the edge kicks off an ACME HTTP-01 challenge with Let's Encrypt. In practice this means:

1. The edge generates a private key and a certificate signing request (CSR) for sub42.nodetonet.com.
2. Let's Encrypt calls back to a well-known URL on the edge to verify ownership.
3. Let's Encrypt signs the certificate (valid 90 days) and returns it to the edge.
4. The edge loads the certificate into its TLS listener and starts accepting connections.
5. At 30 days remaining, renewal happens automatically — no action needed from you.

Multi-port pools — where you run p1.sub42.nodetonet.com through p32.sub42.nodetonet.com — use a wildcard certificate (*.sub42.nodetonet.com) issued via DNS-01 challenge, so every subdomain validates cleanly under one cert. See how wildcard SSL certificates work for the full story. If you point a custom CNAME at Nodetonet (see bringing your own domain), the edge issues a certificate for your custom hostname on first use as well.

The very first request to a freshly-created HTTPS proxy can take an extra second or two while issuance settles. After that, TLS handshakes go through the edge session cache and complete quickly.

You can verify the certificate any time with openssl s_client:

openssl s_client -connect sub42.nodetonet.com:48888 -servername sub42.nodetonet.com

You should see CN = sub42.nodetonet.com and a valid Let's Encrypt chain — no --proxy-insecure flag ever needed.

SNI routing: how the edge picks the right tunnel

The edge runs proxy endpoints for many accounts on a small number of shared public IPs and ports. A single port :443 can belong to dozens of different proxy configurations. When a TLS connection arrives, the edge needs to know — before it can even read the HTTP request — which user's tunnel this belongs to. The answer is Server Name Indication (SNI).

SNI is a TLS extension defined in RFC 6066. Every TLS ClientHello message carries the hostname the client intends to reach, in cleartext, as part of the handshake before any encryption begins. The sequence looks like this:

1.  Client opens TCP connection to edge IP:443 (or custom port)
2.  Client sends TLS ClientHello with SNI = "sub42.nodetonet.com"
3.  Edge reads the SNI field — no decryption needed
4.  Edge looks up which proxy tunnel is registered for that hostname + port
5.  Edge selects the matching TLS certificate and completes the handshake
6.  TLS terminates at the edge; the connection is now plaintext HTTP-proxy protocol
7.  Edge validates the Proxy-Authorization header (username + password)
8.  Edge forwards the CONNECT request down the encrypted agent channel to the device
9.  The device connects to the target and traffic flows

Two critical implications:

• Clients must send SNI. Every modern client does: curl, all browsers, Python's requests, Node's https module, Java, Go, Rust — all send SNI by default. The only clients that don't are genuinely ancient (pre-2012) or misconfigured.
• Always use the hostname, never the raw IP. If you point curl at https://1.2.3.4:443, the TLS handshake carries no SNI, the edge cannot identify the tunnel, and the connection fails with a certificate error. Use the exact hostname the Nodetonet panel gives you.

Connection string examples

The format is identical to HTTP and SOCKS5 — just swap the scheme to https://:

# curl (plain HTTPS proxy)
curl -x https://USERNAME:PASSWORD@sub42.nodetonet.com:48888 https://api.ipify.org

# curl with sticky session (append -session-XXXX to the username)
curl -x https://USERNAME-session-abc1:PASSWORD@sub42.nodetonet.com:48888 https://api.ipify.org

# Python requests
import requests
proxies = {
    "http":  "https://USERNAME:PASSWORD@sub42.nodetonet.com:48888",
    "https": "https://USERNAME:PASSWORD@sub42.nodetonet.com:48888",
}
r = requests.get("https://api.ipify.org", proxies=proxies)
print(r.text)

# Node.js (https-proxy-agent)
const { HttpsProxyAgent } = require("https-proxy-agent");
const agent = new HttpsProxyAgent("https://USERNAME:PASSWORD@sub42.nodetonet.com:48888");
fetch("https://api.ipify.org", { agent });

For geo and carrier targeting, append modifiers to the username in the same way as with HTTP proxies — for example USERNAME-country-tr-session-abc1. See geo-targeting for the full modifier syntax and sticky sessions explained for session pinning details.

HTTPS proxy vs HTTP proxy vs SOCKS5 — when to pick which

If none of the HTTPS-specific reasons apply to you, plain HTTP or SOCKS5 is the simpler path. Throughput is identical once the handshake completes — the TLS overhead only adds latency on connection setup, not on sustained data transfer. For a full comparison of the two plaintext options, see HTTP vs SOCKS5 — which to pick.

HTTPS proxies and sticky sessions

Sticky sessions work identically over HTTPS proxies. Append -session-XXXX to your username and all requests sharing that session token are pinned to the same mobile device exit IP for the duration of the session TTL. This is the correct mode for any stateful flow — logins, multi-step checkouts, account actions — where rotating the IP mid-session would look like account hijacking to the target site. Read sticky sessions explained to understand the TTL mechanics, and see sticky session glossary entry for a quick definition.

Per-client controls: auth, IP allowlist, and quotas

Everything you can configure on an HTTP or SOCKS5 proxy client applies equally to HTTPS proxy clients: username/password authentication, IP allowlist (restrict which source IPs may use the proxy), domain allow/deny lists, bandwidth quotas, expiry timestamps and thread (concurrency) limits. These controls live in the panel under Proxy Clients. See proxy clients per-customer auth, IP allow/deny lists and quota limits per client for details.

You can also verify whether your HTTPS proxy is serving the correct IP using the proxy checker tool, or confirm the exit IP seen by external sites with What is my IP.

Security considerations

A few things worth keeping in mind:

• TLS termination is at the edge, not end-to-end. The edge decrypts your proxy connection to read the HTTP CONNECT request. The subsequent tunnel to the target site is a separate TLS session between you (via the device) and the target. This is standard proxy architecture — no different from any corporate HTTP-intercept proxy.
• SNI is cleartext. The hostname in the SNI field (your subdomain) is visible to a passive observer on the network before the handshake completes. This is a fundamental characteristic of TLS 1.2 and 1.3; TLS 1.3's Encrypted ClientHello (ECH) standard is still not universally deployed. If hiding the proxy hostname itself is a requirement, consider wrapping the connection in an additional tunnel layer.
• Proxy-Authorization is encrypted. Your username and password only travel in ciphertext on the client-to-edge hop — the main practical benefit of HTTPS proxy over HTTP proxy on untrusted networks.
• TCP/IP fingerprint spoofing applies at the device level, not at the TLS layer. If you rely on TCP fingerprint spoofing, it still works the same way regardless of whether the proxy-connection protocol is HTTP or HTTPS.

What's next

• Nodetonet quickstart — full platform walkthrough from account creation to first request.
• HTTP vs SOCKS5 — which to pick — when each plaintext protocol fits better.
• Wildcard SSL certificates — how multi-port pools share one certificate.
• Bringing your own domain — point a CNAME at us and we issue a cert for it.
• Sticky sessions explained — pin a session to one exit IP for stateful flows.
• All Nodetonet features — mobile proxies, rotating pools, geo-targeting and more.