Telegram Desktop 获得了一种全新的绕过封锁的方法，它将即时通讯工具的流量伪装成通过安全连接进行的普通网站访问。这项于2026年8月21日推出的实验性 WEB-代理技术，通过基于 HTTPS 或 WebSocket 的 WebView 传输来传递 MTProxy 数据，这使得数据流与合法的网页浏览流量无异，为在受限条件下访问该服务开辟了新的前景。
隐形隧道如何工作
这项创新的核心在于使用复用数据流，该数据流通过应用程序内置的浏览器引擎进行传输。客户端保留 MTProxy 惯用的加密和帧结构，但不再使用直接的 TCP 连接，而是通过单个 WebView 会话发送所有数据。特殊的帧格式（OPEN、DATA、WINDOW 和 CLOSE）允许将 Telegram 的多个逻辑连接打包到一个受保护的通道中，从外部看就像是标准的网页加载过程。
在服务器端，有一个中继器接收这个单一数据流，并将其仔细地拆分成单独的连接，传输给标准的 MTProxy。中间节点不解密内容，也不知道最终的目的地址，仅充当盲目的信使。在应用程序完成初始转换之后的所有阶段，有效负载都保持不透明，这保证了即使通过额外节点传输，隐私也能得到保障。
域名的双重生活
WEB-代理在一个普通的 HTTPS 域名上运行，该域名继续承载一个完整的公开网站。用于代理的桥接页面仅在存在基于配置计算得出的特殊参数时才会被激活。任何普通请求都会获得该资源的标准主页，这为躲避自动检测系统提供了可靠的掩护。
数据传输方式的选择被硬编码在为每个特定会话生成的中间页面中。本地适配器将 TCP 连接转换为逻辑流，并将它们整合到绑定到原始域名的单个传输会话中。这种架构允许利用普通虚拟主机和内容分发网络的基础设施，而不会引起对代理活动的注意。
实现的技术细节
完整的部署和协议文档已在 tproxy-server 代码库中发布，其中描述了所有配置细节。用户需指定规范主机名和 MTProxy 密钥，通过 HMAC-SHA256 可以从中推导出连接桥的唯一标识符。只有携带特定 43 字符参数的精确 GET 请求才能开启访问特殊页面的权限，其他访问则作为普通访问处理。
连接链接的格式为 https://t.me/webproxy?server=proxy.example.com&secret=... 或使用 tg://webproxy 协议。端口 443 和 HTTPS 协议是 WEB-代理类型规范中强制要求且固定的。所描述的协议确保了请求的严格类型化，并避免了桥接功能的意外激活。
项目的当前状态
该开发目前处于概念验证阶段，包括桌面版实现、实验性的 Android 客户端以及对 iOS 支持的计划。所有平台使用相同的中间页面、帧格式和服务器组件，这简化了测试和后续开发。客户端和服务器部分的统一化允许快速进行修改，并在不同操作系统上验证假设。
WEB-代理的出现展示了向更复杂方法整合合法网络基础设施的转变。使用标准的浏览器机制和安全协议增加了过滤系统的难度，这些系统必须在全面封锁 HTTPS 流量和保持普通服务可用性之间做出选择。该技术的实际价值将取决于其对自适应流量分析方法的抵御能力，以及在不损失性能的情况下扩展的能力。
AI观点
从机器数据分析的角度来看，所提出的 WEB-代理方案在结构上重复了一种更早的将流量伪装成合法 HTTPS 的技术——“域名前置”，该技术在2010年代中期就已普及，并被描述为一种通过 SNI 和 HTTP Host 不匹配来隐藏真实连接目标的方法。大型 CDN 提供商后来在基础设施层面限制了这种可能性，这迫使开发人员寻找其他伪装途径——Telegram 的途径就是在 WebView 内使用参数化的桥接页面。这种情况展示了审查与规避技术之间斗争的周期性：每个技术解决方案都有效，直到过滤系统适应新的流量模式。WEB-代理能否抵御对数据包时间特征和会话量的分析，还是说开发人员将不得不再次寻找新的伪装层级？
end-content
