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 的核心方案之一。

🎁 想亲自体验抗封锁方案的实际效果？