Encrypted Client Hello: what ECH hides and what proxies see

Originally published on proxymint.

Encrypted Client Hello (ECH) hides the hostname in the TLS handshake. How it works, what stays visible, 2026 support, and why it often stops behind a proxy.

TL;DR

• ECH encrypts the hostname in the TLS handshake. The real server name and ALPN list travel in an encrypted inner ClientHello, while the outer hello shows only a shared public name such as cloudflare-ech.com.
• The key comes from DNS. Sites publish it in an HTTPS record, so ECH depends on the client fetching that record, ideally over encrypted DNS.
• The IP address, DNS lookups and traffic patterns stay visible. ECH hides a site well only when many sites share one front and one public name.
• Browsers usually drop it behind a proxy. Chrome applies ECH keys on direct connections only, and Firefox fetches the key through a proxy only when it resolves names itself.

Key takeaways

• Check the record before blaming the browser. Run dig on the HTTPS record and look for an ech parameter; no key means no ECH on any path.
• Test each path separately. Read the sni= line on Cloudflare's trace page directly and through the proxy, in each browser you use.
• Choose proxy DNS on purpose. HTTP CONNECT or socks5h resolves names on the proxy side; local resolution keeps ECH possible but sends lookups from your own network.
• Do not expect ECH to change how a target scores you. The site decrypts the inner hello and still sees the IP, the headers and the client's handshake.

Read the full guide on proxymint, with the commands, tables and sources.