HTTPS 只加密頁面內容，並非一切都被隱藏。了解你的 ISP、Wi-Fi 營運方或電信業者仍能看到什麼：目的 IP、DNS、SNI 與流量模式。
網址列上的鎖形圖示代表頁面內容和你在網域之後輸入的路徑已被加密——並不代表你的連線完全隱形。HTTPS 從設計之初就不是為了隱藏中繼資料，而中繼資料恰恰是你的 ISP、Wi-Fi 營運方或行動電信業者這類路徑上的觀察者仍能掌握的大部分資訊。本文逐一拆解這些殘留資訊：目的 IP 位址、DNS 查詢、TLS 交握中的伺服器名稱，以及流量的時序與體積。
關鍵要點
- HTTPS 加密的是你讀到與輸入的內容，而不是你在和誰通訊。 無論是否加密，目的 IP 位址在每個封包上都是可見的。
- DNS 通常是最大的洩露點。 除非使用加密 DNS，否則你的解析器——往往是 ISP 的解析器——會以明文看到你查詢的每一個網域。
- TLS 交握過去也會洩露同一個網域，途徑是 Server Name Indication（SNI）。Encrypted Client Hello（ECH）在瀏覽器與伺服器都支援時能補上這個缺口。
- 流量的時序、體積與節奏會洩露粗粒度的行為模式，即使每一個位元組的內容都已加密——這不是靠某個瀏覽器設定就能解決的。
- 沒有任何設定能讓你在所在網路中完全隱形。 務實的目標是建立一個準確的心智模型，了解哪些資訊仍會暴露，而不是產生「完全隱私」的錯覺。
明確的分界：HTTPS 加密了什麼，沒加密什麼
HTTPS 把你的 HTTP 請求與回應——頁面內文、表單欄位、Cookie，以及 URL 中網域之後的路徑與查詢字串——都包裹在 TLS 加密之內。位於你和伺服器之間網路路徑上的觀察者，無法讀到你搜尋了什麼、送出了什麼表單，也無法知道你在某個網站上正在讀哪篇文章。這是 HTTPS 相對於明文 HTTP 所提供的真實且重要的保護。
TLS 沒有隱藏的是「信封」本身：誰在傳送這個封包、它寄給了誰、大致有多大，以及是什麼時候送出的。這些欄位必須維持可讀，路由器才能完成轉送工作——而這正是路徑上的觀察者仍能蒐集到的資訊。本文接下來就逐一拆解這些殘留資訊。
殘留資訊一：目的 IP 位址
你傳送的每一個封包都以明文攜帶著它的目的 IP 位址——TLS 加密的是負載，而不是路由器用來投遞封包的網路層標頭。你的 ISP（或路徑上的任何一方）始終能看到你正在連線哪些 IP 位址，並可以把它與已知的代管位址範圍做關聯。
實際上，這個訊號往往比聽起來要弱。只有單一租戶的專用伺服器才會把一個 IP 直接對應到一個身分。但現代 Web 的大部分內容都架設在共享基礎設施之上——CDN 與雲端負載平衡器會用同一段位址為成千上萬個互不相關的網域提供服務。觀察到一次連線指向某個 Cloudflare 或 AWS 的 IP，只能說明「背後是某個共享入口」，而無法說明這背後成千上萬個網站中你造訪的具體是哪一個。共用代管大幅削弱了這個訊號，但並未徹底消除它，因為有些 IP 位址範圍仍然專屬於單一服務；而且結合下面提到的 DNS 或 SNI，這個 IP 往往起到「印證」而非「揭露」目的地的作用。
殘留資訊二：DNS——通常是最大的洩露點
在瀏覽器能連線到任何東西之前，都必須先把網域名稱解析成 IP 位址，而這次查詢和隨後的 HTTPS 連線是完全獨立的兩次互動。除非你特地設定了加密 DNS，否則這個查詢會以明文送往解析器——預設情況下是 ISP 營運的解析器——它會看到你即將造訪的確切網域，並附有時間戳記。
這是許多人低估的一處殘留資訊，因為瀏覽器本身的連線是加密的，但在此之前的網域查詢卻不是。解法是加密 DNS（DNS over HTTPS 或 DNS over TLS），目前多數現代瀏覽器都已原生支援。關於其運作機制、即使使用 VPN 也常見的、會導致洩露的錯誤設定，以及如何自行測試你的解析器，可參閱《DNS 洩露防護》——如果這正是你最擔心的一環，非常值得通讀全文，因為它通常是最值得優先修復的一處。
殘留資訊三：TLS 交握中的 SNI
即使 DNS 已經完成解析，建立這次 HTTPS 連線的 TLS 交握過去也曾把同一個網域再洩露一次。為了讓一個 IP 位址能承載多個 HTTPS 網域（同樣是 CDN 背後的常態），你的瀏覽器會在最初的 ClientHello 訊息中帶上一個 Server Name Indication（SNI） 欄位，指明它想造訪的網站——這樣終結 TLS 的伺服器才知道該出示哪張憑證。TLS 1.3（RFC 8446）加密了隨後交握過程中的大部分內容，包括後續協商階段交換的憑證，但 ClientHello 本身——以及其中的 SNI 欄位——必須在任何加密金鑰存在之前送出，因此依協定本身的必然要求，它一直是以明文傳輸的。這正是TLS 指紋識別用來辨識用戶端軟體的同一個 ClientHello；SNI 是搭乘在同一則明文訊息中的另一個獨立訊號。
Encrypted Client Hello（ECH） 就是針對這個問題的修復方案：它利用伺服器發布在 DNS 中的金鑰，加密敏感的內層 ClientHello——包括 SNI——只在線路上留下一個極簡、通用的外層 ClientHello。Cloudflare 承擔著相當大一部分 Web 的 TLS 終結工作，它宣布正式支援 ECH，推動這項標準走向實際部署。不過要精確理解這到底代表什麼：ECH 只有在你的瀏覽器和你連線的伺服器都支援並啟用它時，才能補上 SNI 洩露的缺口——這是逐連線生效的屬性，而不是一次開啟就能一勞永逸的設定。如果某個網站或 CDN 尚未部署 ECH，無論你的瀏覽器多新，SNI 依然會以明文送出。
這裡還有一層相依關係，直接把這處殘留資訊和上一處串了起來：用來加密內層 ClientHello 的金鑰是發布在 DNS 記錄裡的，所以瀏覽器必須先查到它，才談得上加密。如果這次查詢本身是以明文送出的，那麼在 ECH 有機會遮蔽網域之前，網域早已洩露給解析器了——這正是支援 ECH 的瀏覽器要求該次查詢走加密 DNS 才會啟用 ECH 的原因。加密 DNS 並不是可以拿來替代 ECH 的並行方案，而是 ECH 能夠生效的前提條件。
殘留資訊四：時序、體積與模式
即使假設目的 IP、DNS 與 SNI 全都被完全隱藏，連線本身仍會洩露一件事：流量的「形狀」。每個封包的大小、數量，以及爆發與間隔的節奏，都會完整地穿過加密而不受影響——因為加密負載並不會改變傳送它需要多少位元組，也不會改變你選擇在什麼時候傳送它。
這是一處真實且經過充分研究的殘留資訊——流量分析研究一再證明，即使一個工作階段已經完全加密，其封包大小與時序模式仍可以縮小範圍，有時甚至能辨識出使用者具體在做什麼。它也是四種殘留資訊中最難隨意評估的一種，也不是靠某個瀏覽器設定就能解決的。實際的結論比較保守：理解「已加密」不等於「沒有形狀」，把它當作一個背景事實來看待，而不是去追逐某種變通方案——這裡沒有簡單的緩解措施可以推薦，本文也不打算假裝有。
路徑上還有誰
你的 ISP 是最顯而易見的觀察者，但很少是唯一的一個。Wi-Fi 網路的營運方——咖啡店、機場、飯店——只要你連線著它們的網路，就處於和你家 ISP 完全相同的位置。企業網路通常會部署中介設備，能看到相同的中繼資料（在受管理裝置上，配合安裝的根憑證，有時還能看到更多）。行動電信業者能看到你手機在行動數據上的一切活動，和家用 ISP 能看到路由器流量的方式如出一轍。
VPN 是應對這種情況的常見做法，但值得精確說明它實際做了什麼：它轉移了觀察點的位置——從你的區域網路或 ISP 轉移到 VPN 供應商——而不是從整幅圖景中移除一個觀察者。你的 ISP 現在只能看到你連線到了某個 VPN 伺服器，但 VPN 供應商現在成了那個能看到你目的 IP、以及（取決於其自身的 DNS 設定）你的 DNS 查詢的一方。這是否算是淨改善，完全取決於你是否比信任 ISP 更信任這家 VPN 業者——三種常見工具在隱藏什麼、暴露什麼上究竟有何不同，可參閱《隱私保護工具大比拼：VPN、代理與 Tor》。另一個值得了解、且已經停用的相關方案是 Chrome 的 IP Protection，它特地採用雙跳代理設計，使得任何單一中繼營運方都無法同時看到你的真實 IP 與目的地——雖然廣義上都屬於代理，但這與單一供應商的 VPN 是不同的信任模型。
你可以親自驗證什麼
這一切都不需要你憑空相信。BrowserInsight 的IP 情報查詢會顯示目的伺服器實際能看到的、你目前連線的出口 IP 與網路詳情，VPN/代理偵測則會回報這條連線看起來是 VPN、代理，還是一條普通的住宅或商業 ISP 線路。在連線 VPN 前後，或切換網路前後分別比對這兩項結果，是判斷目前路徑上究竟是誰在觀察你的最快方式。如果你懷疑自己的 VPN 沒有依預期把 DNS 也路由進通道，《DNS 洩露防護》提供了確切的指令，用來檢查究竟是哪個解析器在回應你的查詢；同時，值得一併排查的另一條旁路資訊可參閱《WebRTC 洩露防護》，因為 WebRTC 可能獨立於 DNS 或你 VPN 的通道，單獨暴露你的真實 IP。
誠實的結論
這一切並不是要製造恐慌，也不是一份用來「躲開 ISP」的操作清單——那樣的定位是誇大其詞，本文也不打算這麼假裝。這更像是在建立一個準確的心智模型：HTTPS 透過加密內容做出了真實且重要的貢獻，而 DNS、SNI 與流量形狀，就是剩下的中繼資料——大致也是依照它們「實際能被削減多少」來排序的。沒有任何瀏覽器設定組合能讓你的流量在你所在的網路業者眼中完全隱形——目標是理解實際暴露了什麼，而不是被那個鎖形圖示製造出「沒人能看到任何東西」的錯覺。
常見問題
如果我只用 HTTPS，電信業者能看到我造訪了哪些網站嗎？
看不到具體頁面或其內容，但多數情況下能看到網域。除非使用加密 DNS，否則 ISP 的解析器會看到你查詢的每一個網域。即使使用了加密 DNS，它往往仍能從 IP 位址，以及在未部署 Encrypted Client Hello 時從 TLS 交握中的 SNI 欄位推斷出目的地。
HTTPS 會對電信業者隱藏 URL 嗎？
它會隱藏路徑和查詢字串——也就是網域之後的所有內容——因為這些都在加密的 HTTP 請求內部。它不會隱藏網域本身，如上文所述，網域會分別透過 DNS 以及可能的 SNI 暴露出來。
什麼是 SNI，它對隱私有什麼影響？
Server Name Indication 是 TLS 交握中的一個欄位，用來告訴伺服器你想造訪哪個網域——之所以需要它，是因為一個 IP 位址通常會承載許多不同的 HTTPS 網域。歷史上它一直以明文傳輸，即使 HTTPS 工作階段的其餘部分都受到保護，網域依然會暴露在線路上。Encrypted Client Hello（ECH）是已經落地的修復方案，但只有在你的瀏覽器和目的伺服器都支援時才會生效。
我的 Wi-Fi 網路所有者能看到我透過 HTTPS 瀏覽了什麼嗎？
能看到和 ISP 相同的中繼資料：目的 IP、未加密時的 DNS 查詢，以及未使用 ECH 時的 SNI——只要你連線在他們的網路上，他們就處於和 ISP 相同的路徑位置。但他們仍然無法讀取頁面內容，也無法看到你在 HTTPS 網站上輸入的內容。
VPN 能阻止我的 ISP 看到這些中繼資料嗎？
它改變的是誰能看到，而不是是否有人能看到。你的 ISP 現在只能看到一條通往 VPN 供應商的加密通道，但 VPN 供應商轉而處於能看到你目的 IP 與 DNS 查詢的位置。這是否算是改善，取決於你是否比信任 ISP 更信任你的 VPN 供應商——完整的利弊權衡可參閱我們的隱私工具比較。
