**Telegram 正在开发实验性 WEB 代理**

在 Telegram Desktop 的代码中，发现了一种名为“WEB”的新型实验性代理类型。该发现由 [teleLakel](https://t.me/telelakel/1124) 公布。

WEB 代理的服务器代码仍在开发中，Telegram 尚未认可任何实现方案，因此目前暂时无法尝试这项技术。

**为什么需要这种代理，而不是直接使用 MTProxy？**

现有的 MTProxy 也可以通过 FakeTLS 扩展来伪装成 HTTPS 流量。然而，现代深度包检测 (DPI) 系统已经能够识别这些连接，因为 FakeTLS 仍然与真实的 HTTPS 流量存在一些外部可观察到的差异。

新的 WEB 传输方式使得检测变得更加困难：为了与服务器通信，客户端使用内置的浏览器 (WebView)。它使用浏览器的标准加密机制建立真实的 TLS/HTTPS 连接，这使得 Telegram 流量看起来与普通的网页浏览流量更相似。

**工作原理**

 • 客户端使用隐藏的浏览器，打开代理服务器域名下的一个特殊页面。
 • 该域名也可以继续作为常规网站运行。隐藏的 Telegram 信道仅在请求包含正确的密钥时才会激活。
 • 在该 Web 信道内部，加密的 MTProxy 流量被封装成 WEB 代理的数据帧，并发送到代理服务器。目前，该过程通过 WebSocket 实现。
 • HTTP/WebSocket 流量被重新封装，并在无需解密其中 MTProxy 流量的情况下转发至 MTProxy 服务器。

此功能目前仍在持续开发中，因此协议可能会在正式发布时发生变化。

独立的 [Telemt](https://github.com/telemt/telemt) 社区正在研究具有抗检测能力的协议。此前，得益于该社区对俄罗斯 DPI 系统的研究，Telegram 的开发者[更新](https://t.me/tginfo/4401)了客户端中的 MTProxy，以应对新的检测方法。

该社区指出，Telegram 应该投入更多精力来开发新的抗审查方法。如果 Telegram 不继续改进新的 WEB 代理，它未来可能会失效——即使在真实的 TLS 连接中，如果不采用额外的流量伪装措施，Telegram 流量本身仍可能存在足以暴露其身份的独特特征。

[#Desktop](?q=%23Desktop) [#proxy](?q=%23proxy) [#bans](?q=%23bans)