Every HTTPS connection starts with a short message from your browser. Until recently, that message announced which website you wanted to visit in plain text, even though everything after it was encrypted. Encrypted Client Hello (ECH) closes that gap, and it became a published internet standard in March 2026 (RFC 9849).

ECH is also widely misunderstood. It is not a VPN, it does not hide IP addresses, and it only works when the browser, the website, and DNS all cooperate. This guide explains how it works, what it actually protects, and what it means if you use DNS-level ad blocking such as Pi-hole or AdGuard Home.

The leak ECH closes

When your browser opens a secure connection, its first message is called the ClientHello. It includes the Server Name Indication (SNI), which tells the server which site you want. That matters because many websites share one server address, so the server needs the name to pick the right certificate.

The SNI travels unencrypted. Anyone on the path, such as your ISP, a café's Wi-Fi operator, or a network filter, can read the site name even though they can't see the page. This is true even if you use encrypted DNS, because the name is announced a second time in the handshake. ECH exists to stop that second announcement.

How ECH works

ECH splits the ClientHello into two parts:

1. The site publishes a key. It adds an ECH configuration, which contains a public key, to its DNS records, in a record type called HTTPS (also called type 65). The standard for this is RFC 9848.
2. Your browser looks it up. Along with the usual address lookup, the browser asks for the HTTPS record and gets the key.
3. Your browser builds two ClientHellos. The inner one contains the real site name. The outer one contains a generic stand-in name.
4. The inner one is encrypted with the site's public key and tucked inside the outer one.
5. The server decrypts it. The server that holds the key (usually a CDN) reads the real name, and completes the connection to the right site.

To a passive observer, the connection looks like one to the stand-in name. With Cloudflare, for example, that name is cloudflare-ech.com, and it is the same for every ECH-enabled site on Cloudflare. That sameness is the point: it removes the signal.

Why DNS is part of the story

ECH has a built-in dependency: the key arrives through DNS. That creates two consequences.

• If DNS is unencrypted, the site name leaks anyway. Your lookup for the domain, and for its ECH record, is readable by whoever can see your DNS traffic. ECH only delivers its full benefit when DNS is encrypted too, with DoH or DoT.
• If your resolver doesn't return HTTPS records properly, ECH quietly doesn't happen. The browser never receives a key, so it falls back to a normal handshake.

Who can see what

Notice the last column. The destination IP address is visible in every row. ECH helps most when many sites share an address, as they do on a large CDN, because an observer can't tell which one you chose. For a site on its own dedicated address, the IP itself may identify it.

ECH also doesn't hide anything from the other end. The server or CDN that decrypts the inner message learns the real site name, as it always did. And your DNS resolver still sees the domain you looked up.

Is it actually in use today?

Both sides need to support it, and the picture is uneven.

Browsers. Firefox has had ECH enabled by default since version 119, and Chrome has supported it since version 118. Chromium-based browsers such as Edge and Brave follow Chrome. Safari has been the laggard: sources disagree on its status, so test on your own device. Mozilla's engineering notes say Firefox originally required DoH for ECH, and since Firefox 129 it can fetch the key through the system resolver as well. Chrome's developers said from the start that it would not require DoH, on the argument that some ECH is better than none.

Websites. This is the bigger limit. A 2025 measurement study found Cloudflare to be the only major provider supporting ECH. A site can only use ECH if its host has turned it on, so for most of the sites you visit today, ECH simply isn't in play yet, even with a supporting browser.

DNS. HTTPS records themselves are already common. One passive study found HTTPS-type queries make up roughly 8% of DNS traffic on the network it measured, though many of the answers were incomplete. Having an HTTPS record is not the same as having an ECH key in it, since the record carries other hints too.

Questions people ask

Does ECH hide the sites I visit from my ISP?

Partly. It hides the site name in the handshake, but your ISP can still see the IP address you connect to, and your DNS lookups if they aren't encrypted. For sites behind a shared CDN address, that can mean the ISP learns very little. For others, it learns a lot. ECH narrows the leak, and it doesn't close it.

Does ECH break DNS ad blocking like Pi-hole or AdGuard Home?

No. DNS blocking happens at lookup time, before any connection is made, and ECH doesn't change that: the browser still asks your resolver for the domain's address, and a blocked domain still gets no answer. Mozilla's own FAQ says DNS-based ad blockers work with ECH, with one caveat: make sure the resolver is reached over an encrypted transport, or you leak the names ECH is trying to hide.

What ECH does weaken is filtering that reads the site name off the wire, such as some firewalls, network monitors, and transparent proxies. Mozilla also notes that Firefox won't use ECH when certain DoH opt-outs are configured or when a transparent proxy is in the path, which is how family-safety and enterprise software keeps working.

ECH also doesn't change the limits of DNS blocking. Ads served from the same domain as the content, such as YouTube video ads, still can't be separated at DNS level.

Do I need encrypted DNS to use ECH?

Technically, in Chrome, no. Firefox originally required it and now has a wider path. But without encrypted DNS the benefit largely disappears, because your lookup tells the network the same thing the hidden handshake was protecting. Treat encrypted DNS and ECH as a pair.

What if my resolver blocks or mangles HTTPS records?

Then the browser gets no key and ECH isn't used for that connection. That has two sides.

Some admins deliberately block HTTPS-type lookups to keep tight control, for example with a Pi-hole regex such as .*;querytype=HTTPS. It works, but it also switches ECH off for every device that uses that resolver, so make that choice on purpose.

Handling of these record types has also had rough edges. Pi-hole users have reported cases where a cached empty HTTPS answer interfered with other lookups for internal names. Behavior varies by version, so after any upgrade, test that your resolver returns HTTPS records for public sites and that your internal names still resolve.

Does ECH slow browsing down?

Not noticeably. Mozilla says the extra data is a few hundred bytes, fetched at the same time as the normal DNS lookup.

Can ECH get around censorship?

It was never designed to, and so far it hasn't. Russia began blocking Cloudflare's ECH in November 2024. A 2025 research paper concluded that ECH's help against censorship is currently limited, partly because of its dependence on encrypted DNS, which China and Iran also interfere with. As adoption grows, that may change, but today it shouldn't be treated as a circumvention tool.

What about parental controls and workplace filters?

Filters that work through DNS or a browser extension carry on as before. Filters that depend on reading the site name from network traffic lose that ability for ECH-enabled sites, which is why some enterprise tools disable ECH or move inspection to the endpoint.

How to check your own setup

1. Does the site publish an ECH key? Ask for its HTTPS record:

dig +short cloudflare.com HTTPS

A record that includes an ech= value means the site offers ECH.

2. Does your resolver return it intact? Ask your own resolver the same question and compare:

dig +short @your-resolver-address cloudflare.com HTTPS
dig +short @1.1.1.1 cloudflare.com HTTPS

If the second shows ech= and the first doesn't, something in your DNS path is stripping or blocking the record.

3. Is your browser using it? Open Cloudflare's trace page at https://www.cloudflare.com/cdn-cgi/trace and look for sni=encrypted. If it says sni=plaintext, ECH wasn't used for that connection.

4. Is your DNS encrypted? Use the DNS Tester to check whether your resolver supports DoH and DoT.

What to do about it

• Use encrypted DNS. This is the single most useful step, since ECH depends on it.
• Keep a modern browser. Updates matter more here than settings.
• Test your resolver's HTTPS-record handling if you run your own Pi-hole or AdGuard Home, and again after upgrades.
• Keep expectations realistic. ECH protects the site name in the handshake. It doesn't hide IP addresses, and it works on sites whose hosts have enabled it.
• Don't drop DNS filtering because of ECH. It still works.

Where NxValue fits

ECH needs three things: a site that supports it, a browser that uses it, and DNS that carries the key privately and intact. NxValue Stack covers the third.

• Encrypted endpoints. Every node has its own DoH and DoT endpoints, so the lookups, including the HTTPS record that carries the ECH key, are encrypted between your device and your node. Your network can't read them.
• Blocking still works. Pi-hole or AdGuard Home on your node blocks ad, tracker, and telemetry domains at lookup time, exactly as before. ECH doesn't change that.
• No shared public resolver. Unbound on your node resolves directly from authoritative servers, so the lookups behind your browsing aren't sent to one large public resolver.
• Your own isolated instance. Logs and settings stay on your node, which you can export or delete.

It helps to be clear about the limits. NxValue can't make a website support ECH, and it can't hide the IP address you connect to. It also moves the trust question: your lookups go to your node instead of your ISP or a large public resolver, so you are trusting the node's operator. NxValue's stated policy is not to monitor, store, or sell the queries passing through your node, and the dashboard lets you check what is logged.

If you want to see how it works before deciding, the demo node needs no setup, and the DNS Setup tool generates configurations for Android, iOS, Windows, and more.

Summary

• ECH encrypts the website name that HTTPS handshakes used to send in plain text. It became RFC 9849 in March 2026.
• It works by publishing a key in a DNS HTTPS record, so it depends on DNS to function, and on encrypted DNS to deliver its full benefit.
• It does not hide IP addresses, doesn't hide the site from the server that decrypts it, and doesn't stop your resolver seeing the domain.
• Support is uneven: major browsers have it, but only sites whose hosts have enabled it can use it, and Cloudflare is the main one so far.
• DNS ad blocking still works with ECH. Make sure your resolver is reached over DoH or DoT, and that it returns HTTPS records properly.

Pi-hole is a registered trademark of Pi-hole LLC. AdGuard Home is a trademark of AdGuard Software Limited. Cloudflare is a trademark of Cloudflare, Inc. Firefox is a trademark of the Mozilla Foundation. Chrome is a trademark of Google LLC. NxValue Stack is an independent service provider and is not affiliated with any of these organizations.

Further reading

• RFC 9849: TLS Encrypted Client Hello
• RFC 9848: Bootstrapping ECH with DNS Service Bindings
• Mozilla: Encrypted Client Hello FAQ
• Cloudflare: Announcing Encrypted Client Hello
• ECH in Censorship Circumvention (FOCI 2025)