为什么 Telegram 会被封锁,以及封锁的层次
Telegram 在伊朗、俄罗斯部分地区、中国以及一些独联体国家被限制访问。封锁不是一刀切的“拔网线”,而是分层的:
-
DNS 污染:对
telegram.org和 Telegram 的 IP 范围返回虚假解析结果,让你根本无法建立连接。 - IP 封锁:封禁 Telegram 数据中心所在的网段(常见的是 149.154.160.0/20 和 91.108.4.0/22)。这种封锁会直接丢弃 TCP SYN 包,表现为连接超时。
-
深度包检测(DPI):针对 TLS 握手中的 SNI 字段(如
telegram.org或web.telegram.org)进行匹配,发现后立即 Reset 连接。 - 应用层封锁:针对 Telegram 特定的 MTProto 传输协议字节特征进行识别。
理解这四层很重要,因为 MTProto 代理并不能解决前两层问题。如果你的系统 DNS 已经被污染,你需要先手动指定一个未被污染的 DNS(比如 8.8.8.8 的 DoT/DoH),或者直接使用代理服务器的 IP 作为连接目标。MTProto 代理通常配置为 IP 直连,走 TCP 端口(常见为 443 或 4433),这在一定程度上绕开了基于域名的 SNI 匹配,但依然逃不过 IP 封锁。
MTProto 代理与 VPN 的本质区别
很多人把代理和 VPN 混为一谈,但对 Telegram 而言,它们是两个世界的东西:
| 特性 | MTProto 代理 | VPN (WireGuard/OpenVPN) |
|---|---|---|
| 协议 | Telegram 自定义的 MTProto 二进制协议 | 标准加密隧道协议 |
| 封装内容 | 仅 Telegram 流量 | 全部设备流量 |
| 加密方式 | 应用层加密(在传输层之上) | 传输层加密 |
| 伪装能力 | Fake-TLS 模拟 HTTPS 流量 | 取决于工具,可被指纹识别 |
| 资源占用 | 极低,单核 128MB 内存可支撑千人在线 | 相对较高 |
| 搭建难度 | 低,单二进制可运行 | 中高,需要配置密钥和路由表 |
| 被封锁风险 | 中等偏下(Fake-TLS 后更低) | 高(如果 IP 用于多种翻墙则很快被封) |
一个关键的差异:VPN 是“全系统代理”,而 MTProto 代理只能代理 Telegram 客户端内的流量。这意味着它不会影响你浏览其他网站。这既是优点(其他流量不经过中间节点,隐私风险更小),也是缺点(如果你还需要访问被墙的网站,或者你的其他应用也需要翻墙,MTProto 代理帮不了你)。
另一个技术细节:MTProto 代理不是一个 HTTP/HTTPS 代理,它是一个 Telegram 专用的服务端适配器。客户端发送的请求直接进入加密的 MTProto 隧道,没有标准的代理握手过程。这也意味着你不能在 Chrome 或 Firefox 里配置这些代理地址。
Free-MTProto-Proxies 项目能给你什么
如果你不想去 Telegram 群组里求私人代理(私人代理通常维护昂贵且容易跑路),你可以关注持续在更新的公开代理列表。典型的例子是 free-mtproto-proxies 项目,它每天自动扫描并发布会话数量高、上线率稳定的代理,且支持 Fake-TLS 的代理会特别标注。
该项目提供的代理以 tg:// 链接形式发布。订阅一份这样的列表比自己在浏览器里搜随机端口(比如 127.0.0.1:8080)要安全得多,因为公开列表已经过滤了已知的可疑节点。
你需要理解这个列表的局限性:它是“公共”的,意味着上千人可能同时使用同一个代理。当一个代理的跨境带宽被榨干,即使它在线,你的连接也会延迟极高(Jitter 超过 300ms 就会明显卡顿)。所以,从列表里挑代理时,优先选那些连接数显示低于 3000 的节点。如果信号强度显示为绿色但依然无法发送消息(表现为“正在等待网络”),直接把该代理切换掉,没必要做过多的尝试。
在 Android 和 iOS 上配置代理:两种完全不同的路径
Android(Telegram 官方版)
Android 上的配置极其简单,无需安装任何额外应用。步骤如下:
- 打开 Telegram,进入“设置” -> “数据和存储” -> “代理”。
- 点击右上角的“+”号,选择“使用代理”。
- 输入服务器地址(通常为一个 IP 或 UUID 伪装地址)、端口(默认给 443),以及一个可选的密钥(Secret)。
如果你复制了一个 tg://proxy?server=... 链接到剪贴板,打开 Telegram 它会自动弹窗询问是否使用该代理。链接格式类似:
tg://proxy?server=158.247.222.123&port=443&secret=ee1c4b3a0f5d92e9c8a7b6c5d4e3f2a1
关键点:那个 secret 参数不是备选的。如果代理启用了 Fake-TLS(secret 以 ee 开头的模式),你直接输入明文地址而不带 Secret,连接会握手失败,并提示 “Proxy error” 或者直接无响应。务必粘贴完整链接。
iOS(Telegram 官方版)
iOS 的限制比 Android 严格得多。苹果强制所有网络连接都必须走系统级的 Network Extension,而第三方应用无法将代理设置注入到 Telegram 的进程里。因此,在 iOS 上,你不能像 Android 那样在应用内直接输入代理地址。
你唯一的办法是设置一个全局 HTTP/HTTPS 或 SOCKS5/Shadowsocks 代理,让系统环境接管。这个代理可以是:
- 通过快捷指令(Shortcuts):用一个快捷指令手动配置 Wi-Fi 的 HTTP 代理,但这个 HTTP 代理必须是标准协议,不能是 MTProto 协议。
- 安装第三方客户端(如 Shadowrocket 或 V2Box):在这些工具里配置一个支持 MTProto 入站协议的节点,然后将 Telegram 的流量通过系统代理规则放行。注意,Shadowrocket 这类工具只支持将 MTProto 作为服务器端的一种入站协议,不支持客户端直接连普通的 MTProto 代理。
实用的做法是:找一个HTTP 代理服务器(而不是 MTProto),配置进 iOS 的 Wi-Fi 设置里。但这也意味着所有流量都走这个代理,如果它不支持加密,你的 DNS 请求依然可见。
最实际的方案:如果你一定要用 MTProto 代理,而手上只有一台备用 Android 设备或电脑,可以在那台设备上运行一个 HTTP 代理转发到 MTProto 出口,但这对绝大多数用户来说过于复杂,不推荐。
桌面端(Windows / macOS / Linux)
桌面端的配置和应用内设置几乎一样。
-
Telegram for Windows:安装官方桌面版。打开“设置” -> “高级” -> “连接类型”。选择“使用自定义代理”,类型选
MTProto,填入主机、端口和 Secret。这里有一个坑:Windows 桌面版对 IPv6 支持不好。如果代理服务器只监听 IPv6,你需要在系统网络设置里禁用 IPv6,否则连接会一直在Connecting...状态(表现为状态栏蓝色箭头旋转)。 -
Telegram Desktop (Linux):相同步骤。如果遇到打不开,检查你是否安装了
libproxy相关包,因为某些发行版(如 Arch 的入门配置)缺少该库会导致 UI 假死。
超过 95% 的情况下,配置失败的原因都出在 Secret 长度不是 64 个十六进制字符上。官方生成的 Secret 首字符是颜色表示,比如红色开头的 ee,蓝色开头的 dd,它们都是 32 字节。如果你从网页复制到的 Secret 少了一位,连接会直接报 401 UNAUTHORIZED 错误。
故障排查:当代理“在线”却连不上的时候
你按照配置连了,但黄色感叹号一直闪烁。不要在首阳下盲目换代理,先按顺序检查:
1. 检查代理地址的排版问题。 确认端口是否被逗号分隔,比如 158.247.222.123,443 这种格式是无效的。标准是冒号或无符号。
2. 检查 SNI 是否被特殊处理。 Fake-TLS 代理的 Secret 里通常包含端口信息(如果你用的是强制端口模式)。如果你的代理开启了 DS 加密,而你的 Telegram 客户端版本低于 8.5,就无解。
3. 检查 DNS。 即使你上了代理,Telegram 客户端依然会用系统的 DNS 解析 telegram.org 以获取 API 服务器 IP。如果污染严重,手动在系统设置里将 DNS 改为 1.1.1.1 或者使用 DoH 配置。
4. 检查 UDP 或 TCP 的 MTU 问题。 在某些强制 WiFi Portal 的环境(比如机场或酒店公共 Wi-Fi),MTU 只有 1400,而 TCP MSS 协商不佳时会导致 Telegram 的图片发送一直失败。手动设置 MTU 为 1400 可以解决。
5. 观察日志里的具体报错。 在一个单命令行工具 curl -v 上,你不会得到任何有用信息,因为 MTProto 不是 HTTP。你需要使用 tcpdump 抓包,看是否有 Connection reset by peer。
sudo tcpdump -i eth0 host 158.247.222.123 and tcp port 443
如果看到一个数据包进来然后立刻有 RST 回去,说明该 IP 的 443 端口被针对性的黑名单过滤了,不是代理本身坏了。换端口或换 IP。
Fake-TLS 与流量指纹的现实弱点
现在很多新代理默认开启 Fake-TLS 模式和内置的 Cloudflare CDN 握手,这使得流量变成类似访问 microsoft.com 的 ClientHello 包。但你要清楚,这种伪装不是终极防护:
-
关于 Fake-TLS 的实现细节:连接过程会先构建一个合法的 TLS 1.3 头部,包含 SNI 字段(比如
www.bing.com),但加密后的记录层内容依然不是有效的 TLS 应用数据。防火墙如果对客户端 Hello 后的第一个响应包做深层校验,发现回应时 CT 类型字节错误,就会将其标记为特征值,从你第一秒握手就被识别。 -
熵太重:对一个 TLS 会话来说,握手累积的熵通常保持在某个范围。MTProto 代理需要在建立 TLS 后打自己的
transport header(4 字节,包含abef或efef等魔术数字),这些附加帧是独一无二的。 - 持续运行风险:一个代理上线两周后,其 IP 有 78% 的概率被某个大规模 DPI 供应商的指纹库收录。届时连接表现为握手成功后一个微小的停顿(约 500ms 延迟),随后立即断连。这种衰减几乎是不可避免的。私密代理(不公开订阅列表)通常能坚持两个月左右,公开列表上的一般不超过 6 到 7 周。
作为用户,你无法解决指纹问题,只能接受“代理是消耗品”这个现实,每次断连就换下一个。同时跑 3 个代理进行手动轮换,比死守一个体面代理的体验要好得多。
FAQ
为什么连接代理后 Telegram 能收到消息但发不出去?
这在代理的服务端表现为响应延迟过高(通常是后端连接的 MTProto DC 数据中心未在你的地域建立长连接池)。通知走快通道,但你的发送请求等待了握手确认。解决方法:更换为同一时区区域内的代理节点(例如使用欧洲代理而身处国内,通常会距离欧洲数据中心更近)。
MTProto 代理代理的流量能隐藏我的真实 IP 吗?
是的,对于 Telegram 的服务器而言,它看到的是代理服务器的 IP。但对于你的网络运营商(ISP),只要他们监控 TCP 数据流,他们依然能看到你的 IP 正在与代理 IP 进行高频率大数据包传输。这种流量不会伪装成 HTTPS,所以 ISP 通过 DNS 查询记录也能推测。不能把代理当成“不可证伪的隐身”。
使用免费代理是否会让我的聊天记录泄露给代理主?
技术上不能。MTProto 协议对应用数据做了端到端加密,即使代理服务商打算截获,也只能看到加密后的一堆字段。唯一需要警惕的是,代理主能够观测到连接的时间、连接的直流 ID(间接反映你的 IP 地址),并可能拦截你的 DNS 请求(如果你的系统 DNS 未加密)。主动规避敏感设备 IP 连接(比如使用公共 Wi-Fi 连接代理,而不是家里宽带),能对冲这个风险。
如何在电脑上快速设置多个手动代理而不重启?
Telegram 桌面端右上角头像菜单里有一项“代理设置”,这里可以同时放入五个代理,并用下拉菜单选择生效项。你不需要启用/禁用网络接口去测试。当发现连接断了,直接切换下一项。在 Linux 下,也可以通过修改 telegram-desktop.db 里的代理 JSON 值,但现在 UI 管理足够了。
Top comments (0)