鎖已經上了，門牌還掛在外面：ECH 讓 HTTPS 連「你去了哪個網站」都開始藏

先把時間點補上。2026 年 9 月 1 日，掘金上一篇技術長文在開發者社羣流傳，主題是 Android 17 與 OkHttp 5.5.0 攜手落地 ECH（Encrypted Client Hello，加密用戶端問候）。這不是突發新聞，而是一項累積多年的網路隱私工程，隨著新版系統與新版網路庫先後到位，第一次在手機上湊齊了整套零件。開發者圈之所以熱議，理由很直白：HTTPS 用了這麼多年，大家以為該加密的都加密了，結果回頭一看，還有一塊資訊一直晾在外面。

同一把鎖，兩種門牌：HTTPS 到底藏了什麼

用一個畫面來理解。你在手機上打開「https://bank.example.com/account/transactions」，傳統 HTTPS 會把路徑、Cookie、請求內容、伺服器回應全部裝進信封封好。但這封信的信封外面，印著收件人的完整地址：bank.example.com。任何坐在路由器、電信機房或咖啡廳 Wi-Fi 後面的觀察者，看不懂信的內容，卻清清楚楚知道你正在跟哪家銀行來往。

具體來說，域名主要從兩個地方漏出去。第一個是 DNS 查詢，設備得先把域名解析成 IP，如果走的是普通 DNS，查詢內容等於在路上一路裸奔。這一層 Android 早有解法，Private DNS、DNS over TLS、DNS over HTTPS 都能把它包起來。

第二個漏點更刁鑽：TLS 握手中的 SNI（Server Name Indication）。現代網站大量共用 CDN 和 IP，伺服器必須在握手最開始就知道你想連哪個域名，才能挑對證書、導對後端。於是這個域名長期以明文形式出現在 ClientHello 訊息裡。就算 DNS 加密了，觀察者照樣能從 SNI 把你的訪問目標還原出來。

把這兩件事並排放著看，味道就出來了：HTTPS 護住了「你說了什麼」，卻一直沒護住「你去了哪裡」。

RFC 9849 之後：外層信封只寫快遞公司，不寫收件人

ECH 針對的正是 SNI 這個漏點。2026 年 3 月，ECH 正式成為 RFC 9849 標準，做法是把真實 SNI、ALPN 這些敏感的握手欄位，放進一個加密的 ClientHelloInner；對外只留一個 ClientHelloOuter，上面寫的是 CDN 或 ECH 服務商的名字。

效果在大型 CDN 上特別明顯。同一個 IP 可能同時託管數千個域名，鏈路上的觀察者最多只能判斷你的手機正在連 Cloudflare 或 Fastly 這類服務商，沒辦法從 TLS 握手直接讀出背後具體是哪個網站。當然，ECH 也不是隱形鬥篷：目標 IP、連線時間、流量大小還是看得到，只是那個最直白的「域名明牌」被摘掉了。

換句話說，加密 DNS 加上 ECH，等於把 DNS 查詢和 TLS ClientHello 這兩個主要出口一起封住。過去要同時做到這兩件事，得靠瀏覽器自己想辦法；現在手機作業系統親自下場。

Android 17 出介面，OkHttp 5.5.0 出勞力：一場分工明確的接力

Android 17 這次提供的是地基，官方主要增加了幾項網路安全能力：Encrypted Client Hello、區域網路權限隔離、預設證書透明度檢查。其中與 ECH 相關的關鍵介面有兩類：DnsResolver 可以查詢攜帶 ECH 配置的 HTTPS DNS 資源紀錄；Conscrypt 的 SSLSocket 與 SSLEngine 則負責接收這份配置並執行 ECH 握手。開發者還能透過 Network Security Configuration 裡的 domainEncryption 設定，控制全域或單一域名的行為。

但系統有能力，不代表 App 自動受益。Android 應用的 HTTPS 請求可能來自 OkHttp、Cronet、WebView、自研 C++ 網路棧或其他執行環境，系統沒辦法代為改寫所有網路庫的 DNS 和 TLS 流程。這正是 OkHttp 5.5.0 被點名的原因，它把髒活攬了下來。

對照兩邊的分工會更清楚。DNS 查詢階段，OkHttp 並行查 A、AAAA 和 HTTPS RR 紀錄，Android 17 的 DnsResolver 提供原始查詢能力。讀取配置階段，OkHttp 從 HTTPS RR 解析出 echConfigList、ALPN、埠號與 IP Hint，系統端則透過 Network Security Policy 判斷該域名是否允許 ECH。選擇連線階段，OkHttp 會優先保留攜帶 ECH 配置的路線，避免不知不覺回退到明文 SNI。最後到了握手階段，OkHttp 把 ECHConfigList 交給 Socket，由 Android 的 TLS 棧執行真正的 ECH 協商。

一條龍看下來，系統出規格與底層能力，網路庫出整合與判斷，兩邊都到位，ECH 才真的從文件走進手機。

對照著看：這次跟以前的「HTTPS 很安全」差在哪

過去幾年，「HTTPS 無所不在」給了大多數人一種安全感，瀏覽器地址欄那把鎖的圖示成了某種心理保證。但隱私工程的角度一直很冷靜：內容保密與來源保密是兩件事。你加密了對話，卻沒加密通訊錄。

ECH 之後的畫面是這樣的：觀察者知道你的手機連上了某個 CDN 的 IP，知道連了多久、傳了多少量，但沒辦法從握手裡讀出域名。這不是把一切藏起來，而是把最後一塊寫在信封上的地址塗掉。對一般使用者來說，差別可能只是「電信商少知道一點我的瀏覽習慣」；對隱私敏感場景來說，這一塊補上的缺口相當具體。

還沒到全體受益的時候

值得留意的是，這套機制目前有幾個前提。App 得用上支援 ECH 的網路庫，伺服器端也得支援 ECH 才能完成握手；任何一邊沒跟上，連線就會回到原本的模式。Chrome 瀏覽器在桌面上推 ECH 已經一段時間，手機端 App 生態則複雜得多，OkHttp 5.5.0 的接入算是替 Android 陣營開了一扇門，後面還有 Cronet、WebView 等各家隊伍要跟上。

對開發者社羣來說，這波討論的熱度不在「新功能好酷」，而在一個遲來的領悟：原來我們用了十幾年的 HTTPS，域名一直掛在外面給人看。如今鎖升級了，門牌也終於收進信封裡。至於什麼時候大多數 App 的流量真的走上 ECH，那是接下來一兩年才會慢慢揭曉的答案。