ECH — 网站名称在 TLS 握手中的加密 — 于 2026 年 3 月获得标准地位 (RFC 9849, Standards Track)。Firefox 和 Chrome 默认启用它，Cloudflare 几乎将密钥分发给所有客户。然而，大多数用户的 ECH 并未默默生效：浏览器回退到常规握手，提供商仍然可以看到您访问的内容。
下面是如何在一分钟内亲自检查您的 SNI 是否被加密，为什么它通常不被加密，以及在什么场景下 ECH 原则上是无用的（剧透：对于反检测和解析几乎总是如此）。
ECH 隐藏了什么 — 以及什么没有被隐藏
在常规的 TLS 1.3 中，除了第一条消息 — ClientHello 之外，所有内容都是加密的。在其中，SNI 字段以明文形式显示您连接的域名。大多数过滤系统正是通过 SNI 工作：IP 地址在 CDN 后面共享数千个网站，而域名是可见的。
ECH 将 ClientHello 分为两部分：
- ClientHelloOuter — 以明文形式发送，但使用伪域名包装。在 Cloudflare 中，这是
cloudflare-ech.com。 - ClientHelloInner — 真实域名、ALPN 和加密的密码列表，使用服务器的公钥进行加密。
浏览器获取此加密的密钥不是通过连接，而是通过 DNS — 从 HTTPS 记录（类型 65），参数 ech=。由此得出的主要结论是：没有加密的 DNS，ECH 是不可能的。如果 DNS 请求以明文形式通过 UDP/53 发送，观察者在握手之前就可以看到域名，而过滤解析器可以从响应中删除参数 ech= — 这样 ECH 就不会启用。
ECH 完全不隐藏的内容：
- 目标 IP 地址 — 始终可见；
- 流量的大小和时序；
- 客户端的 TLS 指纹（JA3/JA4） — 密码和扩展的集合仍然保留在明文部分；
- 您对网站的身份 — 服务器在解密后看到的所有内容与之前相同。
最后一点是 ECH 与绕过反机器人系统无关的原因。Cloudflare、DataDome 和 Akamai 在服务器端工作：他们并不关心 SNI 是否在传输过程中被加密。如果任务是在自动化时不被发现，实际上是另一个层次在起作用：伪造 TLS 指纹，关于这一点我们在有关 通过 curl-cffi 绕过 JA4 指纹 的材料中进行了讨论。
检查 №1：ECH 现在是否工作（10 秒）
在浏览器中打开：
https://crypto.cloudflare.com/cdn-cgi/trace
找到 sni= 行。可能有两种情况：
sni=encrypted— ECH 工作，网站名称在传输过程中被隐藏；sni=plaintext— ECH 未应用，域名以明文形式发送。
通过 curl 在终端中访问同一地址将始终返回 sni=plaintext — 普通的 curl 不支持 ECH，这也是一个方便的参考：这就是“关闭”的样子。
检查 №2：域名是否有 ECH 密钥（dig，无需浏览器）
只有当域名在 DNS 中有带有 ech= 参数的 HTTPS 记录时，ECH 才会启用。查看原始记录：
dig +short TYPE65 example.com @1.1.1.1
在响应中寻找字节 FE0D — 这是 ECH 扩展的代码，后面跟着 ECHConfig。实际例子：在准备材料时，crypto.cloudflare.com 和我们的域名 proxycove.com 的记录长度为 133–136 字节，包含 FE0D 和伪域名 cloudflare-ech.com 的十六进制形式。而 cloudflare.com 的记录则较短，仅 61 字节：只有 ALPN 和 IP 提示，没有 ECH。这意味着即使在 Cloudflare 的基础设施内部，ECH 也并非对所有域名开放 — 如果某个特定网站没有它，也不要感到惊讶。
如果 dig 报错 ignoring invalid type HTTPS — 您的工具版本较旧，请使用数字形式 TYPE65，如上面的命令所示。
为什么 ECH 不会启用：五个原因
- 加密 DNS 被禁用。 如果没有 DoH，浏览器无法以受信任的方式获取 ECHConfig。在 Firefox 中：设置 → 隐私 → 通过 HTTPS 的 DNS 处于“增强”或“最大保护”模式。在 Chrome 中：设置 → 安全 → 使用安全 DNS。
- 域名根本没有带
ech=的 HTTPS 记录 — 通过上面的命令进行检查。这不取决于您，这是网站所有者及其 CDN 的决定。 - 解析器删除了参数。 企业和提供商的 DNS 服务器通常会返回没有
ech=的 HTTPS 记录。请检查，直接向公共解析器请求记录（@1.1.1.1）并与系统响应进行比较。 - 浏览器标志被重置。 在 Firefox 中，
network.dns.echconfig.enabled和network.dns.http3_echconfig.enabled在about:config中 — 两者都应为true。 - 中间有检查网关。 关于这一点是下一部分。
ECH 如何被破解：两种不同的方案
企业防火墙：静默降级
网络设备供应商发布了针对 ECH 的现成解决方案 — 他们不愿失去流量的可见性。例如，Cisco 从应用程序数据库 VDB 416（2025 年 10 月）开始，将“ECH 服务器”定义为单独的应用程序，并提供两种方法：拦截连接并重建证书，从 ClientHello 中删除 encrypted_client_hello 扩展，或者更简单地在 DNS 层面上：阻止 ECH 域的 HTTPS 记录，切断 DoH/DoT/DoQ，阻止金丝雀域 use-application-dns.net，并仅允许企业服务器的 DNS。
第一种方案的狡猾之处在于，它看起来并不像是阻止。服务器没有看到 ECH 扩展，照常响应，客户端认为 ECH“安全地关闭”，并重新连接时使用明文 SNI。网站打开了，没有错误 — 而域名已被记录在网关日志中。
国家级别：连接直接中断
俄罗斯的例子因其准确性而具有代表性。从 2024 年 11 月 5 日起，过滤仅在同时满足 两个 条件时触发：SNI 值为 cloudflare-ech.com 加上存在 ECH 扩展。单独的任何一个条件都不会引发阻止 — ECH 对其他包装域（例如，测试域 defo.ie 或 tls-ech.dev）是有效的。这并不是通过重置连接实现的，而是通过 静默丢弃数据包：页面挂起并因超时而断开。TCP 基础的 HTTP/2 和 QUIC/HTTP-3 都受到影响。俄罗斯联邦通信监管局当时明确表示，使用 TLS ECH 违反了俄罗斯法律，并建议网站所有者退出 Cloudflare CDN — 一次性有成千上万的合法资源被纳入过滤。
在这种情况下，Firefox 大约一分钟后会尝试重新连接，而不使用 ECH — 这意味着最终会返回明文 SNI，而这正是规范出于安全考虑不建议的行为。如果您观察到“网站加载整整一分钟，然后打开” — 这几乎肯定是它。
当 ECH 不足够时以及替代方案
我们诚实地将任务分解。
- 家庭互联网提供商的隐私。 ECH + DoH 是一个良好且免费的改进。它在不被切断的地方有效。
- 绕过过滤。 ECH 并不是为此设计的，实践证明：一旦它开始干扰过滤器，就有人学会识别并完全屏蔽它。不能依赖它作为访问工具。
- 解析、多账户、自动化。 ECH 并没有提供任何东西：目标网站可以看到您的 IP、您的 JA4 和您的请求历史。只有源 IP 和指纹质量才是重要的。
在所有 ECH 无法处理的情况下，更粗糙但更可靠的层次可以工作：将 TLS 握手移出可观察网络。当流量通过代理时，观察者在您的通道上只能看到与代理节点的连接 — 其中根本没有目标网站的 SNI，无论域名是否支持 ECH。对于日常访问和处理对 IP 声誉敏感的服务，住宅代理 是合适的；对于移动应用和对连接类型特别挑剔的平台，使用 移动代理。
并且不要忘记 DNS：浏览器中的代理并不保证名称通过它解析。DNS 泄漏会准确地暴露您试图隐藏的内容 — 如何检查这一点，我们在有关 检查代理 DNS 泄漏 的单独说明中进行了讨论。如果问题确实在于对通道流量的深度分析，那么要关注的不是 ECH，而是传输本身。
简短检查清单
- 打开
crypto.cloudflare.com/cdn-cgi/trace并查看sni=行。 - 如果是
plaintext— 在浏览器中启用 DoH 并再次检查。 - 如果没有帮助 — 检查域名是否有密钥：
dig +short TYPE65 域名 @1.1.1.1，寻找FE0D。 - 密钥存在，但 ECH 不适用 — 比较公共解析器和系统解析器的响应：很可能参数在传输过程中被删除。
- 连接挂起一分钟后打开 — ECH 在网络层被屏蔽；在这里 ECH 无法提供帮助，需要其他传输。
结论
ECH 是 TLS 隐私的最后一个小漏洞，而不是访问工具，更不是自动化的工具。它依赖于加密的 DNS，在没有任何错误的情况下中途被关闭，并在开始干扰时完全被屏蔽。检查它是值得的 — 上述两个命令只需一分钟。但将其作为绕过封锁或防止反机器人系统的工具是毫无意义的：这些任务在于服务器在另一端看到的是哪个 IP 和哪个 TLS 指纹。