開啟 3 天免費試用
註冊即可免費體驗全部高級功能。
*只限新用戶;每位用戶只可獲得一次試用。


SNI 過濾是一種網絡控制方法:裝置讀取 TLS 連線開首傳送的伺服器名稱,再按該名稱套用規則。若名稱符合封鎖項目,裝置可以丟棄封包、重設連線,或令握手無法完成,而毋須解密之後的 HTTPS 內容。
完整 VPN 指南區分路由元數據與受保護內容。本文只處理 TLS server_name 訊號、執行決定,以及加密客戶端問候(ECH)帶來的界線變化。
關鍵要點
- 多個 HTTPS 網站共用一個 IP 時,SNI 告訴伺服器客戶端想連接哪個主機名稱。
- 傳統 SNI 位於可見的 TLS ClientHello,路徑上的裝置可以把它與規則表比較。
- DNS 與 TCP 可以成功,而連線仍在 TLS 握手階段被重設或逾時。
- ECH 可加密真正 ClientHello,但不會隱藏目的 IP,亦不保證連線可達。
- 一次失敗只能證明路徑未完成,不能單憑現象斷定是 SNI 過濾。
TLS 只在客戶端和伺服器協議保安參數之後,才會保護應用數據。在受保護的連線建立之前,客戶端要先傳送 ClientHello。RFC 6066 定義了 server_name 擴充,讓客戶端告訴伺服器它打算使用哪個主機名稱。[1]當許多虛擬主機共用一個 IP 位址、伺服器必須選擇正確的證書和設定時,這是必需的。
在傳統 TLS 1.2 及 TLS 1.3 握手中,能檢查 ClientHello 的裝置可看到這個名稱。它通常只是 example.com,不是完整 URL;HTTPS 路徑、查詢、頁面文字、密碼,以及加密開始後傳送的訊息,都不在其中。
這個分別很重要。網絡可以在不知道具體頁面的情況下,作出主機名稱層面的政策決定。反過來,當無關的主機名稱共用同一個 CDN 邊緣節點時,單看 IP 位址可能無法確定目的地。SNI 為政策引擎提供一個更精確的名稱作比對。
| 可觀察項目 | 過濾前通常可見嗎 | 不能說明甚麼 |
|---|---|---|
| 目的 IP 與連接埠 | 是 | 共享主機上的準確名稱 |
TLS server_name | 傳統 ClientHello 中可見 | URL 路徑或頁面內容 |
| TLS 版本與擴充 | 是 | 已解密的應用訊息 |
| HTTPS 請求路徑 | 否 | 被動 SNI 過濾器不能據此判斷 |
| 帳戶憑證 | 否,在 TLS 成功後傳送 | 不能單憑 SNI 取得 |
路徑上的裝置先辨認 TLS ClientHello,解析出足以找到 server_name 擴充的內容,按其實作規則正規化主機名稱,再與允許清單、封鎖清單或政策分類比較,然後放行握手或加以干擾。執行點可能位於企業閘道器、學校網絡、接入供應商或其他受管路徑。
匹配可以是精確名稱、域名後綴或分類。精確規則只處理一個名稱;後綴規則可能同時涵蓋子域名;粗疏的字串規則容易誤傷無關名稱。過時清單亦可能遺漏新名稱,或封鎖已轉手的域名。
圖例:1 是客戶端 ClientHello;2 是擷取可見伺服器名稱;3 是政策比較;4 是獲准繼續的 TLS 握手;5 是丟包、重設或其他阻擋結果。連線表示決策流程,不代表 TLS 每一個封包。
過濾裝置毋須回傳說明原因的網頁。它可以靜默丟棄 ClientHello 或其後的握手封包;在所用傳輸支援時注入 TCP reset;亦可以把請求導向政策回應。不同機制會在應用層呈現不同徵狀。
執行裝置須位於客戶端與目的地之間,在 ClientHello 抵達伺服器前觀察它。本地閘道器、學校或企業網絡、接入供應商都可能位於此位置。若企業系統安裝組織證書並終止、重建 TLS,其權限更廣,不應與只讀明文 SNI 的匹配混為一談。
伺服器或反向代理亦可按名稱拒絕握手。不受支援名稱被端點拒絕,屬虛擬主機或存取控制,未足以證明中間網絡進行過濾。封包與伺服器日誌須一併判斷決策位置。
DNS 過濾屬另一層。DNS 決定名稱如何解析,SNI 過濾則評估稍後 TLS 交換中的名稱。客戶端可以取得正確 IP,卻在 ClientHello 失敗;加密 DNS 亦可能保護查詢,而傳統 SNI 仍可見。加密 DNS 界線解釋為何保護一類訊號並不等於隱藏整條連線。
常見表現包括瀏覽器指安全連線失敗、TCP 已建立但之後停頓,或 ClientHello 發出後不久收到 reset。同一 IP 換用另一獲准名稱後可能正常,非 TLS 服務亦可能不受影響。
這些現象都不是 SNI 過濾的唯一指紋。丟包、路由故障、TLS 版本不兼容、證書問題、伺服器拒絕名稱或端點封鎖都可能相似。可靠排查要找首個不同階段,不能由「逾時」直接命名原因。
在獲授權環境,可固定裝置、軟件版本、目的 IP 及時間,只更換網絡。伺服器日誌可確認 ClientHello 是否抵達;擷取封包可顯示 TCP 是否建立及 reset 位置,但記錄含地址、時間與主機名稱,應作敏感資料處理。
當兩個主機名稱共用一個 IP 時,只針對位址的規則會同時影響兩者。能辨認名稱的規則則可以放行一個 SNI 值、封鎖另一個。這種差異是調查主機名稱政策的有力理由,但仍需排除伺服器端虛擬主機行為的影響。
反過來亦有可能:網絡封鎖了共用 IP,令其上每個主機名稱都失敗,與 SNI 無關。這種方式較粗疏,亦可能造成更多附帶損害。網站封鎖概覽比較了名稱、位址、路由和應用層控制。
ECH 把真正伺服器名稱所在的內部 ClientHello 加密給能夠解密它的服務。RFC 9849 定義現行 ECH 協議,RFC 9505 說明 SNI 等識別資料暴露造成的私隱問題。[2][3] 只理解外層交換的被動中間裝置不再直接取得真正內部名稱。
ECH 不會令連線消失。目的 IP、傳輸、封包尺寸、時間與外部 ClientHello 仍可見。外層名稱由 ECH 部署選定,可能指向一個由許多受保護來源網站共用的公開服務。網絡可封鎖該地址、干擾 ECH 發現,或按外層訊號執行規則,只是這類做法可能影響大量無關網站。
部署是一條完整鏈:客戶端、DNS 發現、前端服務與來源路由都要兼容。若回退至非 ECH 握手,傳統 SNI 可能再次暴露,視乎客戶端政策及伺服器可用性。「瀏覽器支援 ECH」不等於某次連線已保護內部名稱。
當 ECH 成功協商時,直接按真實明文 SNI 過濾便不那麼可行,但這並沒有消除所有以名稱為基礎的政策機制。端點在解密內部 ClientHello 後仍可執行政策,受管理裝置亦可能在流量離開主機前已執行規則。
網絡可能轉而使用 IP 信譽、DNS 控制、端點政策、流量分類或粗粒度封鎖。這些方法的準確度和附帶成本各有不同。ECH 改變的是可觀察面,並不承諾普遍可存取。
系統隧道正確建立後,本地接入網絡通常只看到外層 VPN 連線,而非每個內部目的地的 TLS 握手。其後由 VPN 出口一方建立或轉發前往目的地的連線,因此觀察點移到了路徑的另一段。瀏覽器擴充功能、分流、洩漏、未進入隧道的應用,或隧道未建立都會改變結果。
這是觀察界線,不是繞過所有政策的保證。網絡仍可封鎖 VPN 端點、限制其傳輸方式,或對外層連線進行分類,而毋須讀取內部目的地的 SNI。
想在自己的連線上驗證這個觀察位置,可以在 AethoVPN 開啟全局模式,讓所有 App 的流量進入隧道,並在載入要測試的目標之前先連線;此時本地網絡看到的是外層 VPN 連線,而不是該網站的握手。關閉全局模式後,連往你所在地區網站的流量不經 AethoVPN,有助把本地網站的問題與被過濾的境外目標區分開。只在准許使用 VPN 的地方這樣做,並記住它無法對出口一方隱藏目的 IP,也不能令所有過濾系統消失。可用電郵開始 3 日免費試用來做這項對照。
排查時先證明失敗連線經過哪個介面,再分辨外層隧道失敗與隧道建立後的目的站失敗,避免把單一應用請求誤寫成「SNI 過濾封鎖 VPN」。
不是。DNS 把名稱解析為地址資料;SNI 在 TLS 握手中告訴伺服器應選哪個虛擬主機,兩者可獨立受控。
不能只靠 SNI 做到。傳統 SNI 暴露主機名稱,路徑、查詢、標頭與內容都受後續 TLS 保護。
不能。中間裝置、伺服器、防火牆與故障路徑均可能重設連線,須結合時序及對照測試。
它可能解決 DNS 層故障,但不會移除稍後傳統 ClientHello 中的明文 SNI。
不會。TLS 1.3 比早期版本加密了更多握手內容,但要保護真正 ClientHello 中的名稱,仍需要 ECH 及兼容的部署。
可以。封鎖整個地址較名稱匹配粗疏,也較易影響該地址上的無關服務。
只有實際進入已建立隧道的流量才有這條界線。分流、洩漏、僅瀏覽器保護或隧道失敗會有不同結果。
免責聲明:本文僅供一般資訊參考,不構成法律、技術或其他專業建議。我們不保證內容的準確性、完整性或時效性。
來源:
Sources checked 2026 年 9 月 12 日。
延伸閱讀:
註冊即可免費體驗全部高級功能。
*只限新用戶;每位用戶只可獲得一次試用。