Does ECH Replace a VPN? What Each One Actually Hides

You enable Encrypted Client Hello, open a site, and the connection works. Someone asks whether the VPN is still needed, and the honest answer is that the two features hide different things from different parties. ECH protects parts of the TLS handshake that can otherwise reveal the server name you asked for. A VPN puts your traffic inside a tunnel that ends at an operator's endpoint. Confusing the two leads to either overpaying for protection you already have or believing you have protection you never had.

What the handshake exposes without ECH

A TLS connection begins with a ClientHello, and in the older form the intended server name travels in the clear inside it. Anyone positioned to observe the handshake, from a network operator to a passive sensor on a path, can read that name even though the application data afterwards is encrypted. The destination address is visible too, so the name is often confirming information rather than the only signal.

That is the specific leak ECH targets. It is a narrow leak, and narrowing it is worth doing, but it is not the same as concealing where your traffic goes.

What ECH actually changes

With compatible client and server support and the necessary configuration, ECH encrypts an inner ClientHello under keys published by the server, so an observer sees an outer handshake that does not carry the real server name. The traffic still goes to the same address, at the same times, in roughly the same volumes. Timing and size remain observable, and the destination IP was never part of what ECH encrypts.

Support is not universal either. Not every client, service or individual connection uses ECH, and you cannot infer its presence from a padlock icon or from having changed your VPN country. Diagnosing it requires looking at the handshake, not at the browser's decoration.

What the VPN changes instead

A VPN carries covered traffic inside a tunnel to an endpoint, so the observer nearest you sees a connection to the VPN rather than to the destination. That changes who can observe what, and it changes the address the destination sees. It does not encrypt anything the application did not already encrypt, and it does not hide the connection from the VPN operator, who is by construction in the path.

The two compose naturally: an application can use TLS and ECH while the tunnel protects the network segment around it. Neither one establishes what every party can see or retain, because the parties occupy different positions in the path.

Where DNS fits

An unprotected DNS query reveals the name to the resolver and to anyone observing that path, which is a separate exposure from the TLS handshake. ECH does not encrypt DNS, and a VPN only changes the resolver's identity if you also send your queries through the tunnel or use an encrypted resolver. People enable one of the three and assume the other two followed.

Check the resolver path separately from the handshake path. They fail independently and they are configured in different places.

How to tell which layer you are looking at

Ask what the observation would reveal. If the question is which server name was requested, the handshake and the resolver are the relevant layers. If the question is which network the traffic went to and who could see it in transit, the tunnel is. If the question is what account did what on the site, neither of them helps, because the website still receives the request and any identity you supplied.

Keep certificate verification and DNS policy intact while you investigate compatibility. Disabling a check to make a test pass changes what the result means rather than showing what ECH protects.

Write down which layer you have actually enabled before adding another one. Most of the confusion here comes from assuming a single control covers a request, its name, its destination and its identity at once.