HTTPS, DoH, ECH and a VPN Hide Different Things
Each mechanism removes a different observer from the path, and none removes all of them. Compare what is protected before adding another tunnel.
Adding a VPN to a browser that already uses HTTPS, DoH and ECH does not stack three protections into one; it changes who is in a position to observe what. Each mechanism removes a different party from a different exchange, and each leaves something behind. The useful question is not which is strongest but which observer you are trying to remove, because the answer decides whether a tunnel helps at all. A comparison of the remaining observers is more useful than a feature list.
Four mechanisms, four observers
Start with the four relationships and the party each one is designed to keep out of. The table below is the one I use in review, because it forces the conversation to name an observer instead of a technology.
| Mechanism | Relationship it protects | Observer it does not remove |
|---|---|---|
| HTTPS | The application's TLS connection to its named endpoint | The access network still sees the destination address |
| DoH | The DNS exchange to the selected HTTPS resolver | That resolver sees every query |
| ECH | The sensitive ClientHello fields, where supported and accepted | Destination addresses, and DNS if it is not covered |
| VPN | Covered packets carried to the VPN peer | The VPN operator sees the destinations |
The table's value is what it refuses to say. It does not rank the mechanisms, and it does not claim that using all four removes all four observers. A cloud web application that already terminates TLS at its own edge is protected from the access network for that exchange, and no tunnel improves that particular property. What a tunnel can change is which network sees the outer packets and which operator is now on the path.
What HTTPS actually hides
HTTPS protects the application exchange between the client and the endpoint the certificate names. It does not hide the destination address, it does not hide that a connection happened, and it does not hide the name unless ECH is in play. Certificate validation is part of the protection, not a formality around it.
A VPN does not need to terminate that TLS, and a forwarding exit should not be treated as the application's authenticated endpoint. If a design has the exit decrypting, that is a different architecture with a different trust statement.
What DoH and ECH move, and what they leave
DoH moves the DNS exchange to an HTTPS resolver, which means that resolver sees your queries instead of the local network's resolver. That is a real change and a bounded one: the selected resolver becomes a party that can correlate queries with the addresses you then connect to, which is precisely the correlation RFC 8484 discusses. Encrypted transport does not make the recipient unaware of the queries it answers.
ECH protects the sensitive part of the ClientHello so that a passive observer on the path cannot read the intended server name. It depends on a supporting deployment and on acceptance by the server and the network, and it leaves other channels in place: destination addresses remain visible, and DNS may still reveal the name.
The other thing ECH does not do is prove itself. A connection that uses TLS 1.3 is not evidence that ECH was accepted, and a browser that offers ECH to a server that does not support it falls back quietly. Check the connection's actual state rather than inferring it from the protocol version.
That is the general shape of this whole comparison: each mechanism is verified at its own layer, and none of them is verified by another one's success.
What a VPN moves, and what it adds
When web traffic enters a VPN, the access network sees the outer exchange with the VPN peer instead of the individual application connections, and the VPN operator takes a position on the onward path. That is a move of the trust boundary, not the removal of one. The operator now sees which destinations you reach, even if the content stays encrypted end to end. Whether that is an improvement depends entirely on which of those two parties you trust less.
Keep the application's HTTPS and the intended resolver protection in place while you do this. A tunnel is not a substitute for certificate validation, and turning off a resolver's protections because the traffic is tunnelled removes a control without replacing it.
Choosing from the requirement
State the actual requirement, because that is what decides the design. Private-resource admission, a managed egress point, a specific access-network threat and device authorization are four different needs with four different answers, and a company that only uses public cloud applications still has to decide authorization and data handling. Extra layers can be appropriate without being interchangeable. A more complicated connection is not an anonymity measurement, and it is not a security argument on its own.
The ECH specification, RFC 9849, is worth reading for what the mechanism does and does not cover, and it is honest about the channels it leaves alone. Compare the mechanisms by the observer each one removes, write that observer down, and then decide whether the extra layer is addressing it. If the answer is that the observer was already outside your threat model, the tunnel is cost without benefit.