就在很多人以为 HTTPS 已经万无一失时，AdGuard 用一次 7.5 系列的更新（Windows 端确认为 7.17，Android 与 Mac 同步跟进 CoreLibs 升级）把隐私保护的拼图又补上了一块：**Encrypted ClientHello (ECH)** 的实验性支持又向前迈了一大步，同时还把 DNS-over-HTTPS 的即时过滤带到了所有设备。如果你对“运营商到底能看见我访问了哪些网站”这件事耿耿于怀，这次更新值得你花五分钟了解。
ECH 到底是什么？为什么它被称为隐私的最后一块拼图
每次打开一个 HTTPS 网站，浏览器都会先跟服务器打声招呼——这就是 TLS 握手中的
ClientHello 消息。问题在于，哪怕页面内容全程加密，这个最初的“你好”里却**明晃晃地写着你要去的网站域名**（Server Name Indication，简称 SNI）。你的运营商、机场 WiFi 管理员、甚至楼道里的监听设备都能一眼看到你正在访问 `example.com`，虽然不知道你在里面干了什么，但“去了哪里”毫无秘密可言。
ECH 就是来解决这个尴尬的。它把 ClientHello 整个加密，只有你和目标服务器才能解开，中间人只能看到你连接了某个支持 ECH 的 CDN 节点，但具体是哪个网站——猜去吧。换句话说，ECH 让 HTTPS 终于实现了从第一包到最后一包的全链路加密。
AdGuard 7.5 是怎么做到的？全局 ECH，不挑浏览器
过去 ECH 只能靠浏览器单打独斗，比如 Chrome 或 Firefox 开启实验选项，而且还得看网站脸色。AdGuard 的思路则完全不同：直接在系统层面接管流量。
在 Android 版的更新日志里，开发者甚至开了一句玩笑——“支持 ECH 的第一步，竟然是先学会「压制」它”。这是因为 AdGuard 内部有一个 `pref.dns.block.ech` 开关，配合 `pref.https.redirect.doh` 可以先把原生的 ECH 请求拦下来，然后再由 AdGuard 自己重新发起一条真正支持 ECH 的连接。这样一来，**手机上任何一个 App、任何一款浏览器，只要流量走 AdGuard，就能享受到 ECH 带来的隐私增益**，完全不用等应用开发者适配。
Windows 版本 7.17 和 Mac 版本 2.10 同样内置了这个实验性功能，而且为了让 ECH 顺利工作，AdGuard 首次把
DNS 过滤默认开启。原因很简单：ECH 所需的加密参数要通过 DNS HTTPS 记录获得，如果不用 AdGuard 自己的 DNS 保护模块，就没法在本地拿到这些参数去完成全局加密。
三步检查你的 ECH 是不是真的生效了
AdGuard 提供了一个极其简单的验证方法：
- 在高级设置里确认 Block ECH 处于关闭状态，同时 DNS 保护 已启用。
- 打开 Use Encrypted ClientHello 实验选项（Windows/Android 的位置在“高级设置”，Mac 在“网络”相关配置中）。
- 访问
crypto.cloudflare.com/cdn-cgi/trace，若看到 sni=encrypted；或者前往 www.cloudflare.com/ssl/encrypted-sni/ 看到 SSL_ECH_STATUS: success，就说明 ECH 已经成功运行。
如果测试没通过，先别急，目前 ECH 需要服务端也支持（Cloudflare 旗下网站大部分都已开启），而且由于是实验功能，有时确实会小幅影响浏览速度，官方正在针对这部分做性能优化。
不止 ECH：DoH 即时过滤与底层引擎大升级
AdGuard 7.5 系列带来的隐私提升远不止 ECH。CoreLibs 过滤引擎从 v1.12.80 一路更新到 v1.14.59，引入了几项硬核改进：
- On-the-fly DNS-over-HTTPS 过滤：以前对 DoH 请求的过滤比较被动，这次更新后 AdGuard 能够实时拦截并重定向安全 DNS 请求到本地代理，杜绝了 DoH 绕过过滤的可能，意味着任何企图偷偷走加密 DNS 逃逸的应用都会被揪回来。
- ECH GREASE 与参数提取：从拦截到的 DNS HTTPS 查询中提取 ECH 配置，并在流量中注入 GREASE 值，让不支持 ECH 的中间件不至于瞎捣乱，也让支持 ECH 的连接
