Telegram Desktop 获得了一种全新的绕过封锁方式，该方式将即时通讯工具的流量伪装成通过安全连接进行的普通网站访问。这项于2026年8月21日推出的实验性 WEB 代理技术，通过基于 HTTPS 或 WebSocket 的 WebView 传输方式传送 MTProxy 数据，使得流量流与合法的网页浏览无法区分，为在受限条件下访问该服务开启了新的前景。
隐形隧道如何工作
这项创新的核心在于使用多路复用流，该流通过内置在应用中的浏览器引擎进行传输。客户端保留了 MTProxy 惯用的加密和帧结构，但通过单个 WebView 会话发送所有数据，而不是使用直接的 TCP 连接。使用 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 代理是否能够抵御对数据包时间特性和会话量的分析？还是开发者将不得不再次寻找新的伪装层级？
