TG-WEB-Proxy在cloudflare上部署TG代理协议

作者：#tinc 板块：#开发调优 本帖使用社区公益推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的项目是免费使用的，无收费（变相收费、赞助）部分： 是 我的帖子已经打上 公益推广 标签： 是 我的项目属于个人项目，与公司或商业机构无关： 是 我的项目不存在QQ、TG等群组引流： 是 我的项目不存在非运营必要的网站引流： 是 我的项目不存在为他人推广、AFF： 是 我的项目无关联的商业项目： 是 我的站点存在登录，并已接入 LINUX DO Connect： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 本项目通过telegram新推出的web连接协议，把tg流量经cloudflare直接对接到网页版telegram从而实现TG客户端直接使用的方法，且通过CF优选可以提升网络体验，降低延迟，从而避免使用tg时还要开vpn的麻烦事，让tg的使用像微信一样无感，且不用传统额部署在服务器上的要求，只要有cloudflare就能部署，更加简单,我目前计划在源代码基础上添加监控界面、实时通过网页查看速度，查看连接数等功能，敬请期待 telegram_webproxy.txt (31.3 KB) CF-Workers-TGProxy Cloudflare Workers 的 Telegram Web/MTProto WebSocket 代理中继（KWS Lanes）。 telegram_webproxy.js 是一个单文件 Cloudflare Workers 实现：它扮演 Telegram 官方 Web Proxy（td web-proxy）后端，把客户端（Desktop / Android）在隔离 webview 里发起的 WebSocket lanes，直接转接到 Telegram Web K 自己的 KWS 通道（kws{dc}[-1].web.telegram.org/apiws）。 它不再依赖一套独立的 MTProxy / middle proxy 后端：Worker 在本地解开客户端 MTProto 传输层的 obfuscation，再用自己生成的随机密钥重新封一层，拨 Telegram 官方的 Web K 入口。内层 MTProto 载荷始终由客户端端到端加密，Worker 不接触、也不做 mtp 层加解密。 核心能力 当前代码主线包含： td web-proxy 页面：nonce + 严格 CSP，仅允许 frame-ancestors http://127.0.0.1:* Android 应用内 web-proxy 桥（globalThis.TelegramWebProxy 双向 postMessage） 多 lane WebSocket 复用：子协议 tproxy-lane-v1.<token>.<sid> MTProto 传输层 obfuscation 重签（mode 0xef / 0xee / 0xdd，DC 1..5，media 标志） 拨号 Telegram 官方 KWS 端点，子协议 binary HMAC 签名的 bootstrap / session token，以及按会话的 lease 记账 上行 / 下行小包汇聚（upPack = 20KB、dnPack = 32KB、dnMs = 1ms） 显式关闭 WebSocket 压缩协商 代码主路径 flowchart LR TG["Telegram Desktop / Android"] -->|webview 加载 web-proxy 页面| P["Worker 页面 (nonce CSP)"] P -->|postMessage 端口| L["lanes: 每条流一条 WebSocket"] L -->|"tproxy-lane-v1.token.sid"| WS["/api/v1/ws"] WS --> S["mkSession → mkStream"] S -->|"解 obfuscation (AES-CTR)"| RK["mkHead 重新封层"] RK -->|"dial wss://kwsN[-1].web.telegram.org/apiws"| KWS["Telegram Web K / KWS"] webview 页面 → 建立 /api/v1/session（POST，带 bootstrap） → 拿到 session token + X-Carrier-Mode: websocket-lanes → 按流开 lane：/api/v1/ws + 子协议 tproxy-lane-v1.<token>.<sid> → Worker: 解 obfuscation → 重新封头 → 拨 KWS → 中继 为什么从官方 MTProto 转向 KWS 转换 Telegram 官方的 web-proxy 模型（tproxy）需要一套独立后端：客户端连到本地/自建的服务，再经它转发到远端 MTProxy，链路里多一跳、多一套需要自己运维的加解密中转。 本实现把这一整套换掉： 维度 经 middle/MTProxy 的官方 web-proxy 路径 本实现（KWS 转换） 后端 需自建 MTProxy / middle proxy 无，Worker 即后端 传输面加密 代理侧承担 mtp 层与 obfuscation 只落一层 obfuscation（AES-CTR）重签 出站目标 自建中转服务器 Telegram 官方 kws*.web.telegram.org 内层 MTProto 载荷 端到端（客户端） 端到端（客户端，Worker 不接触） 也就是说，转向 KWS 的关键点是：Worker 只处理传输层，不处理 mtp 层。客户端 MTProto 载荷原样透传，Worker 只对 64 字节 obfuscation 头做一次解、一次重签，再走 Telegram Web K 用的同一入口，边缘可达性与线路质量都直接吃官方域名。 性能理论上提升多少倍 以下为基于当前代码路径的理论模型（标记 [推断]），不是本仓库的实测基准。 数据面加解密量下降：相对"经 middle/MTProxy 转发"的路径，本实现每包只做一次 obfuscation（AES-CTR，128-bit 计数器）重签，而不是在代理侧再承担 mtp 层的加解密。数据面 AES 块操作量约降到一半量级 [推断]。 少一跳 RTT：去掉自建中转服务器，客户端 → CF 边缘 → Telegram KWS。[推断] 小包汇聚：上行 upPack = 20KB、下行 dnPack = 32KB + 1ms 观察窗，把高频 tiny frame 压成更少的实际写入。复用 GrainTCP 同一颗 grain 核，其本地回放实测区间为 1.8x–39.8x（固定 512B 风暴下约 39.8x，mixed 小包约 1.8–2.0x）。 单 isolate 承载：单会话最多 128 条 lane，无需把整条会话钉在单个 Durable Object 上。 综合到瓶颈场景，理论提升从 约 2x 起（仅算加解密 + 去跳），小包风暴场景在汇聚部分叠加后可更高。[推断] 设计重点 1. 多 lane 直接替代 Durable Object 公开的 Workers web-proxy 实现大多用 Durable Object 来维持"单条长连接 / 单份状态"。DO 是单线程且需要路由到固定实例，上限和排队都集中在那个对象上。 本实现改为按流拆 lane： 每条 Telegram 流 = 一条独立 WebSocket，子协议里带 sid 所有 lane 仍落在同一个 isolate，session / lease 状态是 isolate 内的 Map 单 lane 上限：laneMax = 8MB / laneItems = 1024 整会话队列上限：qMax = 32MB / iMax = 16384 lane 数上限 128，已用 sid 上限 4096 TG 客户端本身就有多流、并且会自动分流，所以 lanes 让每条流各自背压、各自排队，而不是把整条会话压进一个单线程对象。这正是"不需要 DO、TG 侧也感觉不到单连接限流"的设计依据。 2. 小包汇聚 上下行各自把连续小块先收进一颗薄核，再尽量并成更少的实际写入： 上传: collect -> bundle -> peer.write() 下载: collect -> bundle -> dnPack 门控 -> ws.send() upPack = 20KB：上行单次合包目标 dnPack = 32KB：下行聚合上限；>= 32KB 直接发，< 32KB 进核再等门控 dnMs = 1ms：下行 quiet-window，用来决定何时 flush 目的都是削减高频小 frame 带来的固定调度成本，而不是再造一层重型队列。 3. 鉴权与租约 页面只下发一次性 nonce + 短期 bootstrap（mkBoot，2 分钟） P