If you have ever tried to route a mobile banking app, a ride-share client, or any modern social platform through a proxy and watched it fail without a useful error message, you have encountered SSL pinning. The developer hard-coded which certificate fingerprints the app will trust, and your proxy's certificate authority is not on that list. The TLS handshake completes, the app inspects the certificate, sees an unfamiliar issuer, and kills the connection — silently.
TL;DR: Most "HTTPS proxies" break pinned apps because they intercept and re-sign your TLS traffic. Nodetonet does not — we forward raw encrypted bytes using SNI routing, so the app's pin check always sees the real server certificate.
What SSL/TLS certificate pinning actually does
A standard TLS client trusts any certificate that a recognized Certificate Authority has signed. On a default Android install that is roughly 150 root CAs. Pinning narrows that dramatically: the app embeds the exact certificate (or its public key hash) it expects inside its binary at compile time and rejects every other certificate — no matter how many CAs vouch for it.
The check happens client-side, after the TLS handshake completes but before any application data flows. It is invisible on the wire. You cannot negotiate around it, and you cannot suppress it by manipulating DNS. The only way to handle pinning correctly is to never substitute a certificate in the first place.
SSL pinning is now standard practice for:
- Mobile banking and payment apps
- Ride-share and food-delivery platforms (Uber, Lyft, DoorDash)
- Major social networks — Instagram, TikTok, Telegram, WhatsApp, Twitter/X all pin
- Healthcare and government apps handling regulated data
- Any app whose developers worry about a hostile network intercepting credentials
Why most "HTTPS proxies" break pinned apps
The cheap way to inspect HTTPS traffic is a man-in-the-middle (MITM) intercept: the proxy terminates TLS, presents its own CA-signed certificate to the client, then opens a fresh TLS connection to the real target and copies data between them. Tools like mitmproxy, Charles, Fiddler, and Burp Suite all do this — it is fine for debugging workflows where you install the proxy's CA on your device.
For pinned apps it is a wall. The instant the app sees the proxy's certificate instead of the hard-coded expected certificate, it closes the connection. There is no error dialog, no fallback, and no way to tell from the outside whether the app failed because of the pin or some other reason.
Many commercial scraping proxy providers fall into the same trap: they advertise "HTTPS proxies" but their infrastructure performs MITM to let them log or cache requests. That approach is fundamentally incompatible with certificate pinning.
How Nodetonet HTTPS proxies work instead
Our edge servers use SNI routing (also called transparent TLS passthrough). Here is exactly what happens on each connection:
- Your tool connects to the Nodetonet proxy endpoint over TCP.
- The edge reads the TLS
ClientHellomessage. This message contains the Server Name Indication (SNI) extension — the hostname you are connecting to — and it is sent in cleartext before any encryption begins. - The edge opens a TCP connection to that hostname and forwards every subsequent byte verbatim in both directions.
- The TLS handshake completes directly between your client and the real server. The edge never decrypts anything.
client -- TLS ClientHello (SNI: api.example.com) --> edge
edge -- reads SNI only, opens TCP to api.example.com:443
client <-- raw TLS bytes in both directions, no decryption --> serverBecause we never substitute a certificate, the pin check always sees the real server's certificate. Banking apps, social apps, and payment SDKs all pass through without modification.
The trade-off is transparency: we cannot inspect the traffic content, inject headers, or rewrite responses. If you need to modify HTTP traffic you must use an unencrypted HTTP proxy on a non-pinned endpoint. For the vast majority of proxy use cases — routing mobile traffic, geo-targeting, web scraping — this is exactly the right trade.
MITM vs SNI passthrough at a glance
| Feature | MITM proxy | SNI passthrough (Nodetonet) |
|---|---|---|
| Works with certificate-pinned apps | No | Yes |
| Requires client to trust a custom CA | Yes | No |
| End-to-end encryption preserved | No — proxy decrypts | Yes — bytes never decrypted |
| Can inject or rewrite HTTP headers | Yes | No |
| Useful for debugging traffic | Yes | No |
| Useful for routing / geo-targeting | Yes | Yes |
| Survives app updates that tighten pins | No | Yes |
What this means for your use cases
- Mobile app automation. Banking, payments, social — the pin check sees the real server certificate. No CA install needed, no app modification needed.
- No custom root CA installation. Because Nodetonet never presents a substitute certificate, you will never be asked to trust a "Nodetonet" CA on your device or emulator.
- End-to-end encryption remains intact. Even if an edge server were compromised, an attacker would see only ciphertext between your client and the real server.
- SOCKS5 is equally pin-friendly. Our SOCKS5 proxy also forwards raw TCP without MITM. See HTTP vs SOCKS5 for guidance on which to choose.
- TCP fingerprinting is a separate concern. SNI passthrough handles the certificate layer. For the TLS and TCP fingerprint that your client emits, see TCP fingerprint spoofing.
Verifying that no MITM is happening
You can confirm in under a minute using openssl. Route a connection through your Nodetonet proxy and check the certificate that comes back:
openssl s_client -connect example.com:443 -proxy your-proxy.nodetonet.com:PORT -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -subject -issuerThe subject and issuer printed must belong to the real destination's certificate chain — nothing referencing Nodetonet. You can also use our free proxy checker tool or confirm your exit IP with what is my IP. If you ever see a Nodetonet-issued certificate, that would be a bug — open a support ticket at support@nodetonet.com.
Where SNI passthrough fits in the bigger picture
SSL pinning is one layer of trust that mobile apps rely on. The full picture also includes the mobile IP reputation that the app's backend checks. Because Nodetonet routes through real Android devices on real carrier SIMs, your traffic exits from genuine mobile proxies on real 4G/5G networks. That combination — real carrier IP plus unmodified TLS — is what makes the traffic indistinguishable from an ordinary mobile user.
If your workflow involves geo-targeting by carrier or city, sticky sessions for stateful app flows (via -session-XXXX in your username), or rotating across a pool of devices with token groups, all of those work cleanly on top of SNI passthrough. The routing layer and the TLS layer are independent.
For more on how edge servers handle the data plane, see how Nodetonet routes traffic. For the related HTTPS proxy implementation details, see HTTPS proxies and SNI routing.
Get started
Ready to route pinned apps through a real mobile IP? Explore mobile proxies, check the proxy glossary for any term above, or create a free account and ship your first connection in minutes. Questions? Reach us on Discord at discord.gg/nodetonet.