HTTPS、DoH、ECH 与 VPN 隐藏的东西各不相同
每种机制都从链路上移走不同的观察者，而没有一种能移走全部。增加又一层隧道之前，先比较各自保护了什么。
在已经使用 HTTPS、DoH 和 ECH 的浏览器上再加一个 VPN，并不是把三重保护叠加成一层；它改变的是谁有条件观察什么。每种机制都从不同的交换中移除不同的当事方，而且每种都会留下一些东西。有用的问题不是哪一种最强，而是你想移除哪一个观察者，因为答案决定了隧道到底有没有用。比较剩下的观察者，比比较功能列表更有意义。
四种机制，四类观察者
先看这四种关系，以及每一种关系设计上要挡住的当事方。下表是我在评审时用的表，因为它迫使讨论说出一个观察者，而不是一项技术。
| 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 |
这张表的价值在于它拒绝说什么。它不给这些机制排名，也不声称四者全用就能移除全部四个观察者。一个已经在自己边缘终止 TLS 的云 Web 应用，对那次交换而言已不受访问网络窥视，任何隧道都不会改善这一特定属性。隧道能改变的，是哪张网络看到外层数据包，以及现在链路上多了一个运营方。
HTTPS 实际隐藏了什么
HTTPS 保护客户端与证书所指端点之间的应用交换。它不隐藏目的地址，不隐藏发生过连接，也不隐藏名称——除非 ECH 参与其中。证书校验是保护的一部分，不是保护之外的例行公事。
VPN 不必终止那段 TLS，转发出口也不应被当作应用已认证的端点。如果设计让出口解密，那是另一套架构，也有另一份信任声明。
DoH 与 ECH 移动了什么，留下了什么
DoH 把 DNS 交换移到 HTTPS 解析器，这意味着该解析器看到你的查询，而不是本地网络的解析器。这是真实且有边界的改变：被选中的解析器成为一个能把查询与你随后连接的地址关联起来的当事方，而这正是 RFC 8484 讨论的关联。加密传输并不会让接收方不知道它回答了哪些查询。
ECH 保护 ClientHello 中的敏感部分，使链路上的被动观察者无法读到预期的服务器名。它依赖支持该机制的部署，也依赖服务器与网络的接受，并且留下其他通道：目的地址仍然可见，DNS 仍可能泄露名称。
ECH 另一件不做的事是自我证明。使用 TLS 1.3 的连接并不能证明 ECH 被接受，而向不支持的服务端提议 ECH 的浏览器会静默回退。要检查连接的实际状态，而不是从协议版本推断。
这就是整个比较的基本形态：每种机制在各自层面被验证，没有任何一种能靠另一种的成功得到验证。
VPN 移动了什么，又增加了什么
当 Web 流量进入 VPN，访问网络看到的是与 VPN 对端的外层交换，而不是各个应用连接，VPN 运营方则在后续链路上占据一个位置。这是信任边界的移动，而不是移除。即便内容仍然端到端加密，运营方现在也能看到你访问哪些目的地。这是否是改善，完全取决于你更不信任这两方中的哪一方。
做这件事时，请保留应用的 HTTPS 和预期的解析器保护。隧道不能替代证书校验，而因为流量走隧道就关闭解析器的保护，等于移除一项控制却没有替代品。
从需求出发做选择
把真实需求说清楚，因为决定设计的是它。私有资源准入、受管出口点、特定的访问网络威胁与设备授权，是四种不同需求、四种不同答案；只用公共云应用的公司仍然要决定授权与数据处理。额外层次可以恰当，但不可互换。更复杂的连接不是匿名性度量，本身也不构成安全论据。
ECH 规范 RFC 9849 值得一读，看这套机制覆盖什么、不覆盖什么，它对放任不管的通道也很诚实。按每种机制移除的观察者来比较，把那个观察者写下来，再判断额外层次是否针对它。如果答案是那个观察者本来就在你的威胁模型之外，那隧道就是只有成本没有收益。