FakeTLS，是将 MTProto 流被包装在标准 HTTPS（第一条隧道协商消息）中，在该 HTTPS 中传输域（伪造）。在协商了 MTProto 协议-不使用 Fake-TLS 之后，流量便开始使用具有随机长度（dd-密钥）的常规 MTProto 协议。

之前配置过 MTP 的中转教程，数据通过 KCP 封装，经过 UDP 传输，会相对比本文的方式稳定可靠。

如需参考：通过 KCP 中转实现 MTP 代理(UDP) | Telegram 实现稳定代理

本文是通过官方前不久更新出的 fake tls 功能实现的数据伪装，比原本的 mtp 协议更稳定。

事实上 MTP 官方程序原本就有两种代理方式一种是，无混淆；另外一种是增加随机字串，以防止数据包被 ISP 检测。

目前用到的就是第三种实现伪装 tls 传输数据，如果你还使用的旧版本的 MTP 代理，是没有这个功能的，建议重新编译后使用。

安装教程

On Debian/Ubuntu

apt install git curl build-essential libssl-dev zlib1g-dev

On CentOS/RHEL:

yum install openssl-devel zlib-devel
yum groupinstall "Development Tools"

Clone the repo:

git clone https://github.com/TelegramMessenger/MTProxy
cd MTProxy

进行编译

执行 make 进行编译，生成的二进制文件在 objs/bin/mtproto-proxy

make && cd objs/bin

如果你编译失败，可以执行 make clean 清理缓存，重新进行编译步骤。

运行使用

获取 Telegram 通信密匙

curl -s https://core.telegram.org/getProxySecret -o proxy-secret

获取当前 Telegram 代理配置（官方建议每天更新此文件）

curl -s https://core.telegram.org/getProxyConfig -o proxy-multi.conf

生成代理密匙

如果你没有安装 head 可以复制我以下所生成的，修改个别字符即可。

[root@eller MTProxy]# head -c 16 /dev/urandom | xxd -ps
271082e5da56c2877f215c225eb93ffe

启动 MTP 服务端

./mtproto-proxy -u nobody -p 8888 -H 443 -S 271082e5da56c2877f215c225eb93ffe --aes-pwd proxy-secret proxy-multi.conf -M 1

启动成功后，客户连接配置：

端口：443，密匙：271082e5da56c2877f215c225eb93ffe

配置 TLS

此时你根据上述命令默认运行的是不带有 tls 功能的。

在通过 ./mtproto-proxy --help 指令查看到指定 tls 传输的说明

--domain/-D <arg>                  	adds allowed domain for TLS-transport mode, disables other transports; can be specified more than once（
為 TLS 傳輸模式添加允許的域，禁用其他傳輸；可以多次指定）

此时，修改启动命令：

./mtproto-proxy -u nobody -p 8888 -H 443-S 271082e5da56c2877f215c225eb93ffe --aes-pwd proxy-secret proxy-multi.conf -M 1 -D "www.google.com"

MTP 的默认文档中没有说明客户端如何连接，我在 issue 中找到了客户端连接方式：

即其他参数不变，secret 修改为如下字符串

ee+secret+domain 的十六进制

可以通过 python3 生成

>>> print ("ee"+"271082e5da56c2877f215c225eb93ffe"+"www.google.com".encode().hex())
ee271082e5da56c2877f215c225eb93ffe7777772e676f6f676c652e636f6d

注意：这个 secret 只是客户端这样拼接填写，服务端还是保持原始的密匙，即本文的：271082e5da56c2877f215c225eb93ffe

此时通过发现客户端还是无法连接通。

经过不断的反复尝试，发现 Windows 的 TG 可以连通，移动设备却不能使用。（如果你也有该现象，尝试更换代理域名、关闭本地代理工具）

尝试更改 google 域名为 centos 的，经过测试发现可以连通。猜测可能因为我本地 google 代理的问题，也可能是因为其他的的原因，目前没有测试，建议更改为无 ban 白名单的域名。

且最好是支持 TLS1.3！也不是说不是 tls1.3 就不能用，只是因为 mtp 的协议伪装是按照 tls1.3 设计的，这样看起来会更友好一些。当然，我并没有在文档中找到相关的东西，代码也没有去研读，这些全是在 issue 里面所了解到的。

./mtproto-proxy -u nobody -p 8888 -H 443-S 271082e5da56c2877f215c225eb93ffe --aes-pwd proxy-secret proxy-multi.conf -M 1 --domain www.centos.org

客户端连接信息：

IP：xx.xx.xx.xx （有人建议通过域名解析到 IP，客户端填写域名，能有效避免 ISP 审查，该方式也没有大量测试，无法得出具体结果...）

secret：ee271082e5da56c2877f215c225eb93ffe7777772e63656e746f732e6f7267

port：443

供参考：Telegram 为 MTProto 代理使用 3 种类型的密钥：

1. 常规密钥（由 DPI 轻松确定）

2. 前两个字母-dd-随机消息长度（DPI 只能通过连接协商的第一个数据包来确定协议-然后看起来像普通的 https / TLS） 密匙：dd+secret

3. 前两个字母-ee-伪 TLS +随机消息长度（DPI 无法确定协议，第一个消息以及所有后续消息看起来像 HTTPS / TLS）

密匙填写：

第一种是无混淆的即客户端密匙原模原样填写，无需变化。

第二种是有随机填充的，客户端需要在原始的密匙开头加上，如：dd+secret

第三种就是 fake tls 混淆，客户端需要再原始的密匙开头加上 ee，还需要在密匙后面拼接域名的十六进制形式，如：ee+secret+domain_in_hex

在线转换十六进制：https://www.rapidtables.com/convert/number/ascii-hex-bin-dec-converter.html

写入常驻后台运行

cat > /home/MTProxy/objs/bin/run.sh <<EOF
#!/bin/bash
cd "$(dirname "$0")"
./mtproto-proxy -u nobody -p 8888 -H 2083 -S 271082e5da56c2877f215c225eb93ffe --aes-pwd proxy-secret proxy-multi.conf -M 1-6 --domain www.centos.org >/dev/null 2>&1 &
EOF
chmod +x /home/MTProxy/objs/bin/run.sh

写入开机启动

编辑 /etc/rc.local 加入启动脚本

/home/MTProxy/objs/bin/run.sh

开机启动无效，大多数原因是启动脚本没有执行权限，可赋值启动脚本权限进行修复。

chmod +x /etc/rc.local
chmod +x /etc/rc.d/rc.local

关于调试 

在我调试时遇到很多问题，例如你设置的代理域名，执行时提示失败，也并不能代表你不能用。如：

[18121][2020-01-06 18:44:53.583586 local] Not found TLS 1.3 support on domain www.centos.org
[18121][2020-01-06 18:44:53.584159 local] Failed to update response data about www.centos.org, so default response settings wiil be used
[18121][2020-01-06 18:44:53.584188 local] It is recommended to not use workers with TLS-transport[18121][2020-01-06 18:44:53.584269 local] creating 1 workers

反倒是，在我刚开始测试时，得不出任何结论时，这个失败的域名反倒可以连通，浏览器访问也是成功的。

其实这只是 MTP 尝试获取该域名的证书相关信息时，为客户端交换信息做的准备工作。获取不到的就取预设的默认值，也是可以工作的。

这是正常能获取到的信息：

[17763][2020-01-06 18:35:57.923782 local] Successfully checked domain eller.top in 0.112 seconds: is_reversed_extension_order = 0, server_hello_encrypted_size = 1864, use_random_encrypted_size = 1
[17763][2020-01-06 18:35:57.923839 local] It is recommended to not use workers with TLS-transport[17763][2020-01-06 18:35:57.923934 local] creating 1 workers

另外你也可以通过浏览器访问 https://ip:port 进行测试查看证书是否正确，以及是否重定向成功。

关于安全性

如果采用了 tls，对于网路运营商而言，他并不能看到具体传输的数据内容，只可以分析出你的数据包是 HTTPS。能获取的信息只有服务器 IP 地址、以及域名证书。

由于获取到的信息有限，你可以借此将你的服务器实现更深度的隐匿。

例如你使用谷歌云的服务器，代理域名设置为 google.com。

使用亚马逊（aws）服务器，代理域名设置到 aws.amazon.com。

使用 DO 的服务器，代理域名设置到 digitalocean.com。

这样一来，你的 IP 地址、证书一致，对于其他人而言这就是一个正常的网站，无论是从正常访问还是探测的角度都很难识别出这是 MTP 代理服务器。

参考

Telegram наносит ответный удар DPI и блокировкам — Fake TLS