Does Your ISP See What Sites You Visit? SNI, ECH & VPN

TL;DR: HTTPS encrypts the content of your connections, but your ISP can still see which domains you visit. The reason is SNI (Server Name Indication): the domain name is sent in plaintext during the TLS handshake, before encryption kicks in. Encrypted DNS (DoH/DoT) only hides the DNS query — it does not close the SNI leak. ECH (Encrypted Client Hello) encrypts SNI in the browser, but only for sites that support it and only when DoH is enabled. A VPN is the only complete solution: it hides SNI, DNS, and the destination IP for all apps on your device, regardless of whether the site supports ECH.

What Your ISP Actually Sees

A common misconception: "I'm on HTTPS, so my ISP doesn't know what I'm doing online." This is half right. HTTPS encrypts the content of a connection — the page body, files, form data, passwords. But the fact of the connection and its destination remain visible to everyone between you and the internet.

Think of it like a letter in an opaque envelope: the postal worker can't read the text, but they can see the recipient's address on the envelope. HTTPS works the same way. Your ISP logs at least three things for every connection:

• Destination IP address — which server your device connected to.
• The domain name — via the SNI field in the TLS handshake (more on this below).
• Connection metadata — timestamps, traffic volume, session duration.

What's inside the pages, what you read, what you type into forms — all of that stays encrypted and inaccessible to your ISP. But "which websites you visit" falls squarely into the metadata category that encryption doesn't hide and that gets logged.

SNI: Why the Domain Leaks Even Over HTTPS

The root of the problem lies in the TLS protocol and the Server Name Indication (SNI) field. Here's how it works.

When a browser opens an HTTPS connection, the first step is a TLS handshake. The browser sends the server a ClientHello message that includes the domain it's trying to reach. This is the SNI field. It exists because a single IP address can host hundreds of different websites, and the server needs to know which certificate to present before key exchange happens.

The problem: in standard TLS 1.3, the SNI field in the ClientHello is sent in plaintext. Encryption — AES-GCM or ChaCha20-Poly1305 — kicks in later, after session keys are negotiated. But SNI leaves your device before that, in plain readable form.

This is exactly what DPI (Deep Packet Inspection) equipment reads. ISPs install DPI hardware on their networks that can inspect packets in real time and extract the SNI from TLS traffic without decrypting the full connection. So even when you visit a site over HTTPS, your ISP knows the domain — and can log or act on it. The content of the pages is still protected; DPI sees only metadata, not data.

Doesn't Encrypted DNS (DoH/DoT) Fix This?

Many users, after learning about SNI, enable encrypted DNS — DoH (DNS over HTTPS) or DoT (DNS over TLS) — and assume their ISP can no longer see which sites they visit. This is a common misconception worth clearing up.

DoH and DoT close only the DNS query leak. Without encrypted DNS, your ISP sees two sources of domain information: the DNS lookup (before the connection) and the SNI field in the TLS handshake. With DoH or DoT configured, the DNS query travels encrypted — your ISP can't see it. But the SNI in the TLS handshake remains in plaintext. SNI has nothing to do with how you obtained the server's IP address — whether through encrypted DNS or not, SNI goes out in the open during the handshake.

In short: encrypted DNS removes one of two domain-leakage channels, but not both. Your ISP still sees the domain via SNI. For a deeper look at DoH and DoT, see Encrypted DNS: DoH and DoT Explained; check for active DNS leaks with DNS Leak: How to Check.

What Is ECH (Encrypted Client Hello)?

ECH is a TLS extension designed specifically to encrypt the SNI field and other sensitive handshake parameters. Its full name is Encrypted Client Hello.

The challenge is harder than it sounds: you can't encrypt the first message before keys are agreed upon. ECH solves this paradox by splitting ClientHello into two layers:

• Outer ClientHello — visible to every node on the network path. Contains only a generic cover domain (public_name). For sites behind Cloudflare this is cloudflare-ech.com. ISPs and DPI see only: "user is connecting to something on Cloudflare's network." This is the "envelope."
• Inner ClientHello — encrypted with the server's ECH public key. Contains the real SNI, ALPN (application protocol), supported cipher list, and other parameters that actually identify the target site. This is the "letter inside the envelope."

How ECH Hides SNI Step by Step

• The browser requests an HTTPS DNS record (HTTPSSVC, type 65) for the target domain. The server publishes its ECH public key alongside the cover domain in this record.
• The browser encrypts the Inner ClientHello (with the real SNI) using the ECH public key and places the result inside the Outer ClientHello. Only the cover domain appears in the outer header.
• ISPs and DPI equipment see only the Outer ClientHello: "user is connecting to Cloudflare" — but not which specific site within Cloudflare's network.
• The server decrypts the Inner ClientHello using its ECH private key, learns the real target domain, and routes the connection to the right backend. From the user's perspective everything looks transparent.

Browser support: ECH is enabled by default in Firefox starting with version 119 (released October 2023). Chrome also supports ECH. Both browsers require DoH to be configured — without it, the browser can't fetch the ECH key from the HTTPS DNS record privately, because the DNS request itself would leak the domain.

ECH Limits: What It Does NOT Hide

ECH is a genuine step forward for privacy, but it doesn't close the problem completely. Here's what your ISP can still see even with ECH working correctly:

• Destination IP address is still visible. ECH hides the domain but not the server's IP. If a site has a dedicated IP (a smaller resource, not behind a major CDN), your ISP can identify the domain from the IP alone. On large CDNs — Cloudflare, Fastly — one IP serves hundreds of thousands of sites, so the IP reveals very little.
• Browser-only protection. ECH is implemented in the browser and its TLS library. Other apps on your device — messaging clients, email, streaming services, games — use their own TLS stacks and don't support ECH. Their SNI fields remain in plaintext.
• Only for ECH-supporting sites. A site or its CDN must publish an ECH key in an HTTPS DNS record. Today this is mainly sites on Cloudflare's infrastructure. Millions of sites on other platforms haven't deployed ECH yet; the browser automatically falls back to standard TLS with a plaintext SNI for those.
• Depends on DoH — and this dependency can be exploited. If DoH isn't configured, the browser requests the HTTPS DNS record in plaintext, which itself reveals the domain. Some corporate and ISP networks deliberately strip ECH configs from HTTPS DNS records, forcing browsers to degrade to plaintext SNI.

Connection Method vs. What Your ISP Sees

How a VPN Closes All the Gaps at Once

A VPN addresses the problem comprehensively — which is why it remains the most reliable privacy tool for everyday internet use. When a VPN is active, all traffic from your device — including TLS handshakes with their SNI fields and DNS queries — passes through an encrypted tunnel before it ever reaches your ISP's network.

Your ISP sees only one stream of encrypted data directed at the VPN server's IP address. Neither the SNI of target sites (it's inside the tunnel), nor DNS queries (those go through the tunnel too), nor real destination IPs — none of this is accessible to your ISP. The only thing it knows: you're connected to a VPN server.

The key difference between a VPN and ECH is coverage. A VPN works at the OS level and captures traffic from every app: messaging apps, email, games, streaming clients. ECH is a browser-level TLS extension and protects only browser connections, and only to sites that support it. If you have a browser tab open, a messaging app running, and a banking app active, the VPN protects all three; ECH protects only the browser.

ECH and a VPN are not in competition — they complement each other. ECH improves browser-level privacy where your ISP cannot strip the ECH key from DNS; a VPN covers everything else and ensures protection regardless of network configuration. For more on how VPN protection works, see How a VPN Protects You from ISP Tracking and How a VPN Works. For the full picture of what a VPN shields against, see What Does a VPN Protect From.

Start using LiMP VPN — and your ISP will see only one thing: an encrypted stream headed to our server. No domains, no apps, no leaks.

Checklist: What to Do

• Enable DoH in your browser. Firefox: Settings → Privacy & Security → DNS over HTTPS. Chrome: Settings → Privacy and Security → Security → Use secure DNS.
• Make sure ECH is active. In Firefox ≥ 119, ECH is on by default when DoH is configured. Chrome supports ECH as well. To verify in Firefox: open about:config and confirm network.dns.echconfig.enabled is set to true.
• Use a trusted DoH provider. For example, Cloudflare (1.1.1.1), NextDNS, or another with a no-logs policy. After configuring, verify with DNS Leak: How to Check.
• Always keep a VPN active on public Wi-Fi. On public networks, DPI can be applied by the network operator, not just the upstream ISP. Also check for a WebRTC IP leak — it exposes your real IP regardless of browser settings.
• Don't rely on Incognito or Private mode alone. It only clears local history and cookies after you close the window — your ISP still sees your SNI and destination IPs throughout the session.
• For complete coverage, use a VPN. It's the only solution that hides SNI, DNS, and destination IPs for all your apps, not just the browser.

Frequently Asked Questions

Does Incognito mode hide my browsing from my ISP?

No. Incognito only clears local browser history and cookies after you close the window. Your ISP sees your traffic the same way in Incognito as in regular mode — SNI and destination IPs are visible in every connection.

Do I need both ECH and a VPN?

They protect at different levels. ECH hides SNI in your browser — but only for sites that support it and only in the browser itself. A VPN hides SNI, DNS, and destination IPs for every app on your device. Together they offer maximum privacy, but if you can only choose one, a VPN is the more comprehensive solution.

Does my ISP see sites I visit over mobile data the same way as Wi-Fi?

Yes, the mechanism is identical. Your mobile carrier sees SNI and destination IPs in every TLS connection, just like a home or office ISP. ECH and a VPN work exactly the same on LTE/5G and Wi-Fi.

Can my employer or a Wi-Fi owner see which sites I visit, not just my ISP?

Yes. Any node on your traffic path — a café router, a corporate gateway, public network equipment — has access to the same metadata: SNI and destination IPs. ECH and a VPN protect against these intermediaries too, not just your ISP.

Does ECH hide my sites from the website itself or from Cloudflare?

No. ECH hides SNI only from intermediaries on the path — primarily your ISP and DPI systems. The server and its CDN know exactly which domain you requested; otherwise the connection would be impossible. ECH protects against ISPs and DPI, not against the destination site.

Does ECH work on all websites?

No. ECH requires the site or its CDN to publish an ECH key in an HTTPS DNS record, and the browser must use DoH. Currently this is mainly sites on Cloudflare's infrastructure. For all other sites the browser falls back to standard TLS with a plaintext SNI — which is why a VPN is more reliable as a universal solution.