MTProto代理是什么？和VPN的区别、设置方法与三个误区
打开一个 tg://proxy?server=...&secret=ee... 这样的链接，Telegram 会弹窗问你要不要启用代理——这就是 MTProto代理。它不是"某种 VPN"，而是 Telegram 自己定义、自己实现、写进官方客户端的一套传输方案，和你系统里装的那个 VPN 客户端是两条完全不同的路。
分不清这两者，最常见的后果是：设了代理发现只有 Telegram 能用，以为自己配错了；或者反过来，以为开了它全机都受保护。下面把结构、设置和边界一次讲清楚。
MTProto 代理到底在代理什么
普通 HTTP/SOCKS5 代理是"通用管道"，谁往里灌流量都行。MTProto 代理不是——它只懂 Telegram 的私有传输协议 MTProto，只能转发 Telegram 客户端和 Telegram 服务器之间的会话。浏览器、游戏、其它 App 的流量它一概不接。
这带来两个直接后果，一好一坏：
- 好处：作用域极小，开销极小。不改动系统路由表，不需要装任何额外软件，Telegram 里点一下就生效，其余网络行为完全不变。
- 代价：它救不了别的任何东西。Telegram 通了，浏览器该打不开还是打不开。
一条代理链接里藏了什么：dd 和 ee 的区别
secret 那一长串十六进制不是随机糊上去的，第一个字节是模式标记，决定了这条连接在网络上"长什么样"。
| secret 开头 | 长度 | 传输模式 | 在链路上看起来像 |
|---|---|---|---|
| 无前缀 | 32 位十六进制（16 字节） | 原始 obfuscated2 | 无明显特征的随机字节流 |
dd + 32 位 | 34 位 | Padded Intermediate（随机填充） | 仍是随机流，但包长分布被填充打乱 |
ee + 32 位 + 域名 hex | 36 位以上 | FakeTLS | 一次指向该域名的普通 HTTPS 握手 |
ee 后面跟的那串不是密钥的一部分，是域名的十六进制编码。想知道某条链接伪装成了谁，把 ee 和随后 32 位砍掉，剩下的转成 ASCII 就是答案：
# 假设 secret 为 ee + 32位密钥 + 域名hex
echo "7777772e636c6f7564666c6172652e636f6d" | xxd -r -p
# 输出：www.cloudflare.com这条命令的实用价值在于：你能亲自确认一条别人给你的代理到底在伪装成什么站点，而不是只看"这个代理很稳"的口头承诺。dd 模式下没有这一段，因为它根本不伪装成 TLS，走的是无特征随机流那条路。
顺带一提，官方 MTProxy 生成密钥用的就是 head -c 16 /dev/urandom | xxd -ps——16 字节，32 位十六进制，比这长的部分一定是前缀或域名，不是更强的密钥。
和 VPN、SOCKS5 的区别：按这张表对号入座
| 维度 | MTProto 代理 | SOCKS5 代理 | VPN 客户端（Reality / Hysteria2 等） |
|---|---|---|---|
| 覆盖范围 | 只有 Telegram | 配置了它的那个 App | 全系统，或按分流规则挑 |
| 是否需要装软件 | 不需要，Telegram 内置 | 不需要（App 内置） | 需要装客户端 |
| 链路伪装 | ee 模式伪装 HTTPS；dd 为随机流 | 基本没有，明文特征明显 | Reality 借真实站点证书；Hysteria2 走 QUIC 混淆 |
| 代理方能看到什么 | 你的 IP、连接时间、流量大小 | 同左，且能看明文目标 | 同左 |
| 适合的场景 | 只想让 Telegram 通 | 临时、低风险场景 | 需要浏览器、下载、其它 App 都通 |
判断规则可以简化成一句：需求是否止于 Telegram。止于此，用专线最省事；超出一点，就别在代理链接上折腾了，直接上客户端，用分流规则决定谁走代理、谁直连（这部分的具体配置见VPN客户端怎么设置分流：智能分流、自定义规则与路由日志）。
怎么设置：两条路径
路径一，点链接。 拿到 tg://proxy?server=域名或IP&port=端口&secret=密钥 形式的链接，在手机上直接点，Telegram 弹窗确认即可。这也是为什么这类链接一般以二维码或短链形式流传——它天然是"一键"的。
路径二，手填。 依次进入 设置 → 数据和存储 → 代理设置 → 添加代理 → MTProto，填服务器、端口、密钥三项。桌面版路径相同，位置略有差异。
填完回到聊天列表，标题栏出现一个小盾牌图标就是已生效。要确认它是否真的在承载流量，把代理临时关掉，看消息是否立刻发不出去——这是最直接的验证方式，比看图标可靠。
三个流传很广的误区
误区一："走了 MTProto 代理，聊天内容代理方也能看。"
不对，但原因值得说清楚。Telegram 的客户端-服务器加密在 MTProto 协议层就已经完成，代理拿到的是加密后的数据，转发时并不解密。代理方能看到的是你的 IP、连接时长和流量大小这些元数据——这些足够勾勒出"谁在什么时候用了多久"，但看不到具体聊了什么。把"看不到内容"和"完全匿名"划等号，才是真正的错误。
误区二："ee 开头一定比 dd 安全。"
两者防护的不是同一件事。FakeTLS 解决的是"流量特征是否显眼"，让链路看起来像普通 HTTPS；它并没有加强加密强度，密钥长度两者完全一致，都是 16 字节。在不做深度流量分析的网络里，dd 的随机流一样能用，甚至因为省掉一层 TLS 封装而更省开销。选哪种取决于所在网络的检测方式，不是"越新越好"。
误区三："代理能给 Telegram 加速。"
代理只改变路径，不改变物理距离。如果代理服务器绕了远路，延迟只会更高。真正决定体验的是代理服务器的地理位置和线路质量——这和挑 VPN 节点是同一套判断逻辑，不是换个协议就能绕开的。
什么时候该从专线切回通用客户端
有三个明确信号：
- 需要在 Telegram 之外做事——点开频道里的外链打不开，说明你需要的是全系统代理，不是专线。
- 要传大文件——MTProto 代理本身不做多路复用优化，大文件场景下通用客户端的传输层调优空间更大。
- 代理频繁掉线且换了几个都一样——问题多半在出口本身，换伪装模式解决不了。
FunMeGo 的做法是把 MTProto 专线作为和主协议并列的一套独立伪装机制：它和 Reality、Hysteria2 互不共用传输层，一套被干扰不影响另外两套。想了解主协议为什么靠"借用真实网站证书"来抗探测，可以看Reality协议是什么？抗主动探测的原理和落地细节；想知道 TCP 通道不顺时该怎么切到 QUIC，见Hysteria2是什么？什么时候该从Reality切过去。
常见问题
MTProto 代理和 Telegram 专线是一回事吗？
基本是一回事，说法不同。"MTProto 代理"指协议本身，"Telegram 专线"通常指服务商提供的、专门跑这套协议的线路。区别在于后者一般有稳定的出口和运维，而公开流传的免费代理往往随时失效。
为什么设置了代理，Telegram 能用但浏览器还是打不开？
这是正常的，不是配置错误。MTProto 代理只接管 Telegram 自己的流量，系统其它程序的网络路径完全没变。需要浏览器也通，得用全系统代理客户端。
免费的 MTProto 代理能用吗？
能连上，但要清楚代价：代理方能记录你的 IP 和连接时间，而免费提供者的动机往往是投放赞助频道或收集连接数据。临时应急可以，长期使用建议用来源明确的线路。
切换到 MTProto 专线需要重新申请线路吗？
不需要。MTProto 专线与主协议是同一条线路上互相独立的入站，客户端里切换即可，订阅地址不变，剩余时长和流量都不受影响。
怎么知道一条代理链接伪装成了什么域名？
看 secret 是不是 ee 开头。是的话，去掉 ee 和随后的 32 位十六进制，剩下部分用 xxd -r -p 转回 ASCII 就是伪装域名。不是 ee 开头的说明没用 FakeTLS，也就没有伪装域名这一说。