️ ◉ CF-Workers-TGProxy — 面向 Cloudflare Workers 的 Telegram Web/MTProto (KWS) 代理中继
🥇 与依赖独立 MTProxy / middle proxy 后端的传统 web-proxy不同，这份代码不再中转去一台自己的服务器，而是把客户端 MTProto 传输层在 Worker 内解出后重新封层，直接拨 Telegram 官方的 Web K 通道（kws*.web.telegram.org）。
🥈 没有 Durable Object：每条 Telegram 流拆成独立 lane WebSocket，各自背压、各自排队，整条会话不再被钉死在单线程对象上。
🥉 传输面只落一层 obfuscation（AES-CTR）重签，内层 MTProto 载荷端到端透传、Worker 不接触；上下行小包分别按 20KB / 32KB 聚合，把高频小 frame 压成更少的实际写入。
补充几点：
重点突破∶
✨ 把 Free Plan 下 Workers 的 Telegram 代理做到不断流：KWS 转换 + lanes 复用，TG下载大文件不断流、不掉速。✨
🔗 项目地址：CF-Workers-TGProxy
🥇 与依赖独立 MTProxy / middle proxy 后端的传统 web-proxy不同，这份代码不再中转去一台自己的服务器，而是把客户端 MTProto 传输层在 Worker 内解出后重新封层，直接拨 Telegram 官方的 Web K 通道（kws*.web.telegram.org）。
🥈 没有 Durable Object：每条 Telegram 流拆成独立 lane WebSocket，各自背压、各自排队，整条会话不再被钉死在单线程对象上。
🥉 传输面只落一层 obfuscation（AES-CTR）重签，内层 MTProto 载荷端到端透传、Worker 不接触；上下行小包分别按 20KB / 32KB 聚合，把高频小 frame 压成更少的实际写入。
补充几点：
- 32KB 是下行聚合上限，不是"必须攒满才发"
- 20KB 是上行合包目标，1ms 是下行观察窗
- 单会话最多 128 条 lane；单 lane 8MB / 1024 条，整会话 32MB / 16384 条
重点突破∶
✨ 把 Free Plan 下 Workers 的 Telegram 代理做到不断流：KWS 转换 + lanes 复用，TG下载大文件不断流、不掉速。✨
🔗 项目地址：CF-Workers-TGProxy
GitHub
GitHub - ToiCF/CF-Workers-TGProxy: 基于 Cloudflare Workers 的 Telegram Web/MTProto WebSocket 代理中继，支持 bridge 鉴权、bootstrap/session 令牌、多…
基于 Cloudflare Workers 的 Telegram Web/MTProto WebSocket 代理中继，支持 bridge 鉴权、bootstrap/session 令牌、多 lane WS 复用、AES-CTR 加密、自定义帧、流控与严格 CSP。 - ToiCF/CF-Workers-TGProxy
- 👎1
