开启 ECH 就能隐藏域名吗？HTTPS、DNS 与代理的保护边界

ECH 能在成功协商时隐藏 TLS 握手中的真实服务器名称，但它不会改变出口 IP，也不能单独隐藏全部访问线索。判断它是否有用，要分清 DNS 查询、TLS 握手和流量出口这三层；浏览器支持 ECH，不等于每次访问都已使用。

ECH 保护的是握手里的什么信息？

浏览器连接 HTTPS 网站时，需要先完成 TLS 握手。SNI 是握手中用于告知服务器“想访问哪个主机名”的字段。网页内容已经加密，并不代表这个初始字段也一定受到同样保护。

ECH 即 Encrypted Client Hello。可以把它理解成两层问候消息：外层保留连接所需的公开信息，内层包含真实目标名称并被加密。因此，旁观者可能仍看到外层公共名称，而不是实际访问的域名。Cloudflare 的 ECH 工作原理说明

这也解释了为什么抓包时“还能看到一个域名”不一定意味着失败。需要先辨认它是外层公共名称，还是实际目标名称；仅凭截图中的一个域名，不能判断整次连接的保护状态。

DNS 查询与 TLS 握手是两个阶段。查询传输经过加密，不会自动把握手中的真实名称一起隐藏；反过来，握手使用 ECH，也不能补救另一条路径上仍然明文发送的 DNS 查询。

客户端还需要取得服务器的 ECH 配置。RFC 9848规定了通过 DNS 的 SVCB／HTTPS 记录传递配置的方法，其中 ech 参数携带相应配置。这里的“HTTPS 记录”是一种 DNS 记录类型，和地址栏里的 https:// 不是同一个概念。

所以，只查到 A 或 AAAA 地址，并不足以判断 ECH 是否可用；查到带 ech 参数的记录，也只能说明存在所公布的配置，不能代替本次握手的结果。它还需要与客户端能力、实际连接的服务器等条件配合。

这个表用于区分作用范围，不代表三者互斥。Mozilla 的 ECH 常见问题说明 ECH 可与 VPN 一起使用，同时明确它本身不重定向浏览器流量。代理是否接管某个应用，仍需按规则、全局与 TUN 的区别单独检查。

RFC 9849 的引言明确指出，ECH 本身不足以保护服务器身份，明文 DNS 查询、可见的服务器 IP 等仍可能提供线索。因此，“真实 SNI 被加密”与“旁观者完全无法推断访问目标”是不同强度的结论。

由此也能推断：如果故障是目标 IP 不可达、服务端停机或代理路由错误，仅改变握手字段的保护方式并不能保证恢复访问。遇到网页打不开，应保留实际错误，再判断是解析、连接还是证书阶段，不要统一归因于 ECH。

先写下浏览器版本、设备是否受组织管理，以及当前解析方式。不要一开始就复制网上的实验性开关参数，尤其不要同时修改多个浏览器标志。

Mozilla 的 ECH 说明指出，Firefox 默认在可用时使用 ECH，相关使用还涉及 DoH；企业策略、家长控制和特定受信代理配置可能影响它。这个说明适用于 Firefox，不能直接作为其他浏览器的设置规则。

可以打开 Mozilla 文档链接的 Cloudflare Browser Security Check，运行页面提供的检查，记录 Secure SNI 等项目的实际结果、时间和错误。页面名称和展示项目可能调整，以当次页面为准。

该检测页自己也提醒：通过测试不代表访问所有站点都具有相同保护，目标域名也需要支持相关技术。应把结果记为当前浏览器访问该检测服务时的观察；检测请求超时，也不能直接推断浏览器完全不支持 ECH。

更深入抓包时，还要注意 GREASE。RFC 9849 第 6.2 节允许发送用于兼容性目的的仿真 ECH 扩展。因此，看到 encrypted_client_hello 字样，不能独立证明真实 ECH 已被接受。没有足够诊断信息时，记录“未知”比凭一个字段下结论更准确。

固定浏览器、目标页面和节点，先保存当前设置，再比较一个明确条件，例如当前代理路径与另一条已知可用路径。记录同一检测项目的结果，不要同时换节点、解析器、浏览器版本和全部高级开关。

如果更换解析方式后结果变化，先按浏览器安全 DNS 排查核对路径；如果提示证书名称不匹配，则转到时间、SNI 与信任链检查。这些对照只能缩小方向，不能单独证明某家服务主动屏蔽了 ECH。

日期／浏览器版本	解析模式／管理条件	代理路径／固定节点	检测项目与结果	修改项／复测结果
待填写	待填写	待填写	成功／失败／未知	待填写

反馈时附上完整错误和测试范围，隐藏账户、订阅地址及敏感访问记录。保留原设置，测试结束后恢复需要的配置。

资料核对日期：2026-10-28。本文核对协议标准与官方说明，未替读者运行浏览器检测，也不据此承诺匿名、提速或站点可达性。