就在許多人以為 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 的連接
