ECH Enabled, Yet SNI Still Visible: How to Check Website Name Encryption in 2026

ECH — the encryption of the website name in the TLS handshake — received standard status in March 2026 (RFC 9849, Standards Track). Firefox and Chrome include it by default, and Cloudflare distributes keys to almost all its clients. However, for most users, ECH silently does not work: the browser falls back to a regular handshake, and the provider still sees where you are going.

Below is how to check in a minute whether SNI is encrypted for you, why it is often not encrypted, and in which scenarios ECH is fundamentally useless (spoiler: for anti-detection and parsing — almost always).

What ECH Hides — and What It Doesn’t

In standard TLS 1.3, everything is encrypted except for the first message — ClientHello. In it, the SNI field with the domain you are connecting to is in plaintext. Most filtering systems operate based on SNI: the IP is shared among thousands of sites behind a CDN, while the domain is visible.

ECH splits ClientHello into two parts:

• ClientHelloOuter — sent in plaintext but with a dummy wrapper domain. For Cloudflare, this is cloudflare-ech.com.
• ClientHelloInner — the actual domain, ALPN, and cipher list, encrypted with the server's public key.

The key for this encryption is taken by the browser not from the connection but from DNS — from the HTTPS record (type 65), parameter ech=. The main implication, which is often forgotten, is: ECH is impossible without encrypted DNS. If the DNS request goes over open UDP/53, an observer can see the domain name before the handshake, and a filtering resolver can strip the ech= parameter from the response — and ECH will not be enabled.

What ECH does not hide at all:

• The destination IP address — always visible;
• The volume and timing of traffic;
• The TLS fingerprint of the client (JA3/JA4) — the set of ciphers and extensions remains in the open part;
• You for the website itself — the server, after decryption, sees everything it saw before.

The last point is the reason why ECH has nothing to do with bypassing anti-bot systems. Cloudflare, DataDome, and Akamai operate on the server side: they do not care whether the SNI was encrypted on the way. If the goal is to avoid detection during automation, a completely different layer is at play: spoofing the TLS fingerprint itself, which we discussed in the article about bypassing JA4 fingerprinting via curl-cffi.

Check #1: Is ECH Working Right Now (10 Seconds)

Open in your browser:

https://crypto.cloudflare.com/cdn-cgi/trace

Look for the line sni=. There are two possible outcomes:

• sni=encrypted — ECH is working, the website name is hidden on the way;
• sni=plaintext — ECH did not apply, the domain was sent in plaintext.

The same address via curl in the terminal will always return sni=plaintext — regular curl does not support ECH, and this is a convenient reference: this is what "off" looks like.

Check #2: Does the Domain Have an ECH Key (dig, No Browser)

ECH will only activate if the domain has an HTTPS record in DNS with the ech= parameter. Check the raw record:

dig +short TYPE65 example.com @1.1.1.1

In the response, look for the bytes FE0D — this is the ECH extension code, followed by ECHConfig. A practical example: at the time of preparing this material, both crypto.cloudflare.com and our domain proxycove.com had a record length of 133–136 bytes containing both FE0D and the dummy name cloudflare-ech.com in hex form. However, the record for cloudflare.com is short, 61 bytes: only ALPN and IP hints, without ECH. This means that even within Cloudflare's infrastructure, ECH is not distributed to all domains — do not be surprised if a specific site does not have it.

If dig complains ignoring invalid type HTTPS — you have an old version of the utility, use the numerical form TYPE65, as in the command above.

Why ECH Is Not Activating for You: Five Reasons in Order

1. Encrypted DNS is disabled. Without DoH, the browser will not receive ECHConfig in a trusted form. In Firefox: Settings → Privacy → DNS over HTTPS in "Enhanced" or "Maximum Protection" mode. In Chrome: Settings → Security → Use Secure DNS.
2. The domain simply does not have an HTTPS record with ech= — checked with the command from the previous block. This is not something you can control; it is the decision of the site owner and their CDN.
3. The resolver is stripping the parameter. Corporate and provider DNS servers typically return HTTPS records without ech=. Check by querying the record directly from a public resolver (@1.1.1.1) and comparing it with the system response.
4. Browser flags are reset. In Firefox, check network.dns.echconfig.enabled and network.dns.http3_echconfig.enabled in about:config — both should be true.
5. An inspecting gateway is in the middle. This will be discussed in the next section.

How ECH Is Broken: Two Different Schemes

Corporate Firewall: Silent Downgrade

Network equipment vendors have released ready-made recipes against ECH — they are not willing to lose visibility of traffic. Cisco, for example, since application database VDB 416 (October 2025) identifies "ECH Servers" as a separate application and offers two approaches: intercepting the connection with certificate re-creation and stripping the encrypted_client_hello extension from ClientHello, or taking a simpler approach — at the DNS level: blocking HTTPS records for ECH domains, stripping DoH/DoT/DoQ, blocking the canary domain use-application-dns.net, and allowing DNS only to corporate servers.

The cunning of the first scheme is that it does not look like blocking. The server, not seeing the ECH extension, responds as usual, the client considers ECH "safely disabled" and reconnects with an open SNI. The site opens, there are no errors — but the domain name has gone into the gateway log.

National Level: The Connection Simply Dies

The Russian example is indicative of its precision. Since November 5, 2024, filtering only triggers when both two signs match simultaneously: SNI with the value cloudflare-ech.com plus the presence of the ECH extension. Separately, neither triggers a block — ECH to other wrapper domains (for example, test defo.ie or tls-ech.dev) passes. This is implemented not by dropping the connection but by silently dropping packets: the page hangs and drops out due to a timeout. Both TCP-based HTTP/2 and QUIC/HTTP-3 are affected. Roskomnadzor then directly stated that the use of TLS ECH violates Russian legislation and recommended website owners to move away from Cloudflare CDN — thousands of completely legal resources caught in the general wrapper were affected.

In such a situation, Firefox attempts to reconnect without ECH after about a minute — meaning it ultimately sends an open SNI, which the specification does not recommend doing for security reasons. If you observe "the site loads for exactly a minute, then opens" — this is almost certainly it.

When ECH Is Not Enough and What to Use Instead

Let’s break it down honestly by tasks.

• Privacy from the provider on home internet. ECH + DoH is a good and free improvement. It works where it is not cut.
• Bypassing filtering. ECH was not designed for this, and practice confirms it: as soon as it started interfering with filters, it was learned to identify and completely suppress it. It cannot be relied upon as an access tool.
• Parsing, multi-accounting, automation. ECH provides nothing: the target site sees your IP, your JA4, and your request history. Only the source IP and the quality of the fingerprint matter.

In all cases where ECH does not cope, a coarser but reliable layer works: move the TLS handshake outside the observable network. When traffic goes through a proxy, an observer on your channel sees only the connection to the proxy node — there is no SNI of the target site at all, regardless of whether the domain supports ECH or not. For everyday access and working with services sensitive to IP reputation, residential proxies will suffice; for mobile applications and platforms that are particularly picky about the type of connection, mobile proxies are recommended.

And do not forget about DNS: a proxy in the browser does not guarantee that names are resolved through it. A DNS leak reveals exactly what you were trying to hide — how to check this was discussed in a separate guide on checking proxies for DNS leaks. If the issue is specifically in deep traffic analysis on the channel, one should not look at ECH, but at the transport itself.

Short Checklist

1. Open crypto.cloudflare.com/cdn-cgi/trace and check the line sni=.
2. If plaintext — enable DoH in the browser and check again.
3. If that didn’t help — check for the key at the domain: dig +short TYPE65 domain @1.1.1.1, look for FE0D.
4. If the key exists but ECH is not applied — compare the responses of public and system resolvers: most likely, the parameter is being stripped on the way.
5. If the connection hangs for a minute and then opens — ECH is being suppressed at the network level; ECH won’t help here, a different transport is needed.

Conclusion

ECH is a carefully closed last gap in TLS privacy, not an access tool and certainly not an automation instrument. It depends on encrypted DNS, can be disabled in the middle without a single error on the screen, and is completely suppressed where it starts to interfere. It is worth checking — the two commands above take a minute. But building on it for bypassing blocks or protecting against anti-bot systems is pointless: these tasks are solved at the level of whose IP and whose TLS fingerprint the server sees on the other end.