2026年8月 Telegram 官方推出最新代理技術
WEB-Proxy 的拆解

2026年8月21日，Telegram 官方發布了一項名為 WEB-Proxy 的全新實驗性反封鎖技術，隨後在 Telegram Desktop 7.1.0 中正式加入客戶端支援。與傳統的 MTProxy 不同，WEB-Proxy 不再試圖「偽裝」成網頁流量，而是讓 Telegram 的代理流量真正運行在 WebView 中，透過瀏覽器引擎發起標準的 HTTPS 或 WebSocket 連線，使審查系統無法將其與正常網頁瀏覽區分開來。

本文將從設計哲學、當前 DPI 封鎖現狀、技術特點和實際效果四個維度，完整拆解這項技術。

一、設計哲學：融入而非偽裝

WEB-Proxy 的核心設計哲學可以概括為四個字：融入而非偽裝。

1.1 從「偽裝」到「融入」的範式轉變

傳統 MTProxy 的策略是「偽裝」——它嘗試讓自己的流量看起來像普通的 HTTPS 存取。但無論偽裝得多好，MTProto 代理的連線行為本身仍然具有可被識別的特徵。舊的 MTProxy 試圖「看起來像」普通網頁流量，而 WEB-Proxy 使用的是真正的 Web 技術棧，網路過濾器面對的是瀏覽器引擎產生的標準 TLS 和 HTTPS 流量。

這種轉變的本質是：不再試圖欺騙 DPI 系統「我看起來像網頁」，而是讓流量從根本上就是網頁流量。

1.2 專用而非全局代理

Telegram 官方繼續在 MTProxy 路線上深耕，而非推出通用 VPN 或全局代理，這背後有清晰的戰略考量：優先解決 Telegram 自身的可存取性問題，同時刻意不提供全局代理能力。如果 WEB-Proxy 變成通用翻牆基礎設施，就會立刻招致審查系統的針對性封鎖，甚至牽連被用作偽裝的普通網站。只服務 Telegram 流量，意味著封鎖它更像封鎖一個通訊應用，而非封鎖通用翻牆服務，從而降低了被「過度針對」的風險。

1.3 零知識中繼：relay 看不到任何內容

WEB-Proxy 的另一個核心設計原則是零知識中繼。伺服器端 tproxy-server 只將 DATA 幀視為不透明位元組——它無法選擇 Telegram 目的地，也無法解密 MTProxy 流。客戶端在本機派生 bridge capability，原始密鑰從不暴露給 JavaScript。這意味著即使代理營運者也無法窺探使用者的通訊內容。

二、當前 DPI 封鎖現狀：2026年的攻防升級

2.1 2026年封鎖浪潮的時間線

2026年是 Telegram 在俄羅斯等地區遭遇最嚴重封鎖的一年。封鎖經歷了多個階段：

• 2026年3月：RKN 在 TSPU（技術對抗手段）系統上部署了新的代理連線檢測演算法。這些演算法能識別 Telegram 客戶端與瀏覽器在建立加密連線時的差異。
• 2026年4月：Telegram 發布客戶端更新，使加密連線的建立方式更像瀏覽器，暫時解決了問題。
• 2026年5月底：TSPU 開始測試新演算法，不僅分析連線建立方式，還分析協議簽名來區分 MTProto 客戶端和真實瀏覽器。5月底至6月，新一輪封鎖浪潮開始。
• 2026年6月5日起：Telegram 在俄羅斯幾乎無法使用。官方 MTProto 代理（包括內建 Fake TLS）被 DPI 完全阻斷，直接影響所有客戶端（Desktop、Android、iOS）和所有主要 ISP（Rostelecom、MTS、Beeline）。

2.2 技術手段：JA4 指紋識別

當前 DPI 系統的核心檢測手段是 JA4 TLS 指紋分析。官方 Telegram 客戶端在 ClientHello 中使用靜態 JA4 指紋，DPI 系統識別後立即注入 RST 封包中斷連線。即使使用 Fake TLS，客戶端的 TLS 棧與真實瀏覽器仍有差異，因此同樣能被檢測到。

社群已經驗證這是客戶端側的問題：使用動態 JA4 輪換的社群 fork 在同一代理和網路上立即可用。

2.3 行為特徵分析

除了 TLS 指紋，2026年的 DPI 系統還會分析流量的行為特徵。分析器會檢查封包大小、封包間隔時間、TLS 連線結構以及其他間接特徵。如果流量行為像代理，僅靠偽裝成 HTTPS 已經不夠了。典型場景是「16KB 問題」：連線成功建立並傳輸初始資料後，突然被限速或中斷。

三、技術特點：WEB-Proxy 的核心架構

3.1 整體架構

WEB-Proxy 的架構可以概括為以下鏈路：

Telegram App
  → MTProto 連線（保持正常 MTProxy 封裝和加密）
  → 本機 WEB 代理適配器（每個 App 連線一個邏輯流）
  → 一個 WebView 傳輸層 + 認證中繼會話
  → 多路複用幀（HTTPS 或 WebSocket 載體）
  → tproxy-server
  → 每個流一個本機 TCP 連線 → 官方 MTProxy

客戶端只配置兩個值：主機名和MTProxy 密鑰。它在本機派生 bridge capability，原始密鑰從不暴露給 JavaScript。WebView 打開 bridge 頁面，用短期 bootstrap token 換取中繼會話，然後使用匹配的伺服器配置檔案所選的載體模式運行。OPEN、DATA、WINDOW 和 CLOSE 幀多路複用所有 Telegram 連線。

3.2 四種載體模式

WEB-Proxy 支援四種傳輸載體模式，透過密鑰/配置檔案選擇，客戶端無需額外設定：

3.3 安全設計

WEB-Proxy 在安全設計上有幾個關鍵特點：

• 域名偽裝：配置的主機名同時是一個正常的 HTTPS 網站。沒有認證憑據的請求會看到公共網站，只有 GET /?bridge=<有效capability> 才會暴露 bridge。
• 簽名密鑰持久化：伺服器端使用持久化簽名密鑰（token.key），密鑰缺失或權限不當會阻止啟動，不會靜默生成臨時密鑰。
• 嚴格的前端策略：bridge 頁面不使用 cookie、瀏覽器儲存、外部資源、worker、frame、媒體、彈窗、下載、表單、裝置權限、剪貼簿 API 或跨域請求。
• 容量控制：進程級限制是強制安全邊界。預設 max_sessions_global 為 128，max_streams_global 為 4096，max_backend_dials_in_flight 為 256。

3.4 部署架構

參考部署架構如下：

Internet :80/:443 → Caddy → 127.0.0.1:8080 tproxy-server → 營運者網站
                                                   → 127.0.0.1:2398 官方 MTProxy

只有 Caddy 監聽外部介面。中繼、管理端點、MTProxy 客戶端連接埠和統計資訊都保持在本機。中繼從不接收客戶端選擇的後端位址，也從不解密 MTProxy 流。Caddy 將所有路徑代理到中繼，不存在單獨的公共路徑供未認證探測者比對。

四、實際效果：當前狀態與實測回饋

4.1 客戶端支援現狀

截至2026年8月，客戶端支援情況如下：

• Telegram Desktop：已在 7.1.0 中正式支援 WEB-Proxy，7.1.1 修復了部分錯誤，7.1.2 進一步改進了 Windows 上的連線問題。
• Android：已在測試版客戶端中支援 WEB-Proxy。
• iOS：尚處於計劃階段。

在客戶端中，使用者只需填寫主機名和密鑰，無需配置連接埠或協議。可共享的連結格式為：

https://t.me/webproxy?server=proxy.example.com&secret=000102030405060708090a0b0c0d0e0f

4.2 部署門檻與成本明顯更高

與傳統 MTProxy 或普通代理相比，WEB-Proxy 的部署門檻、技術難度和成本都明顯更高。它不再是「填個 IP 和連接埠就能用」的輕量方案，而是要求營運者具備完整的伺服器維運能力：需要自備域名和公網伺服器，配置 DNS、Caddy 反向代理、systemd 服務、nftables 防火牆規則，並理解 WebView 載體和幀協議的基本原理。官方安裝腳本雖然提供了一定程度的自動化，但依然面向「乾淨伺服器、Caddy 獨佔 80/443」的場景，已有其他網站的伺服器需要手動整合。對於普通使用者而言，這意味著從「使用公共代理」變成了「營運一個小型 Web 服務」，時間成本、技術成本和持續維護成本都顯著上升。也正因如此，WEB-Proxy 短期內更可能被技術社群、組織使用者和願意折騰的進階使用者採用，而非像公共 MTProxy 那樣大規模普及。

4.3 效果評估

優勢方面：

• WEB-Proxy 的流量從網路審查系統看，與使用者正常存取普通網站幾乎沒有區別。外部觀察者只能看到到你域名的 TLS 流量，沒有 HTTPS 解密就無法將其與存取普通網站區分開來。
• 由於流量來自真實的瀏覽器引擎，TLS 指紋與真實瀏覽器一致，解決了傳統 Fake TLS 的 JA4 指紋暴露問題。
• 四種載體模式可以根據網路環境靈活選擇，增加了適應不同封鎖策略的能力。

局限方面：

• 伺服器端 tproxy-server 仍被官方標記為 proof-of-concept，尚未進入穩定版本。
• 需要自備域名和伺服器，且部署技術難度和成本更高，使用者無法像使用公共 MTProxy 那樣直接獲得服務。
• 運行時 WebView 會在後台載入代理提供商的網頁，提供商可能投放贊助頻道，存在潛在風險。Telegram 官方已就此發出警告。
• 中繼重啟會使現有載體會話失效，客戶端需要重新建立連線。
• 在 macOS WebKit 上，WebSocket 握手可能被串行化，導致 websocket-lanes 模式下連線建立緩慢，此時需改用 websocket 模式。

4.4 與其他方案對比

五、總結

WEB-Proxy 代表了 Telegram 反審查技術的重大演進。它透過將代理流量真正運行在 WebView 中，從「偽裝成網頁」走向「就是網頁流量」，在 2026 年日益嚴苛的 DPI 環境下提供了一條新的生存路徑。其設計哲學——Telegram 專用、零知識中繼、不提供全局代理——體現了官方在「可用性」和「不招致過度針對」之間的精密平衡。

需要特別指出的是，WEB-Proxy 的部署門檻、技術難度和成本都比傳統 MTProxy 更高。它不是面向普通使用者的一鍵方案，而是要求營運者具備域名、伺服器和 Web 服務維運能力。當前 WEB-Proxy 仍處於概念驗證階段，但隨著 Telegram Desktop 和 Android 客戶端的正式支援，以及社群的積極參與，這項技術有望在未來成為受限網路環境下存取 Telegram 的核心方案之一。

🎁 想親自體驗抗封鎖方案的實際效果？