2021 直连 Telegram 代理搭建： MTProxy TLS 白名单，有效防墙

不怕被墙的 MTProxy TLS 代理：白名单MTProxy

使用服务器白名单可以有效防止代理服务器被 GFW 主动探测，进而防止被墙。2021 年亲测可以解决 MTProxy 容易被封锁的问题，感兴趣的可以在自己的服务器上搭建起来，即便是公开分享，也不担心被墙了。

教程如下：

由于MTProto协议在墙内极难生存，在尝试过mtg2.0和掩耳盗铃的伪装页面均告失败之后，白名单模式可能是更值得尝试的方法，下面就分享搭建白名单MTProxy的方法，同样是使用一键脚本。

这个MTProxy + TLS 脚本同样出自 Eller大佬之手，大佬的电报频道：https://t.me/EllerCN

使用 Docker进行安装，首先需要安装 Docker，镜像集成了nginx、mtproxy+tls 实现对流量的伪装，并采用白名单模式来应对防火墙的检测。

关于白名单模式，可以谷歌《白名单防火墙可以有效对抗 GFW 的主动探测》，下面是引用的片段：

[su_quote cite=”——《白名单防火墙可以有效对抗 GFW 的主动探测》- 2020.05.01″]– 服务器的生存挑战我们在我们运营的 SSR 机场的服务器上全部部署了防火墙, 并使用上述策略更新防火墙的白名单.

我们进行了为期 18 天的实验. 在实验中, 所有服务器都没有被墙 (除了一次意外撤除防火墙的事件). 这些服务器工作在 163 线路, CN2 GT 线路和 CN2 GIA 线路. 但是为了保护我们自己的安全, 我们不能公布实验的具体规模.

为了对比, 我们尝试性撤除 4 台服务器的防火墙, 在这几次实验中, 这些服务器在数分钟到一小时之内都被迅速封禁. 这进一步证明了白名单防火墙确实是保护服务器的主要因素. 除了 SSR, 我们还测试了 MTProto 协议. MTProto 是一个早就证明被特征识别的协议.

实验证明, 这样的策略同样可以保护 MTProto. 实验中我们部署了 4 台服务器, 设有保护的两台服务器一直生存至今, 而没有部署防火墙的两台服务器分别在第 20 分钟和第一小时被封禁. 这个实验再次印证了主动探测是墙封禁服务器的必要条件, 即使这个协议早已被特征识别. [/su_quote]

由于白名单模式文章已经发布了一年有余，不知道现在的GFW策略是否升级，所以此方法还需要实验验证。

安装Docker

curl -fsSL https://get.docker.com -o get-docker.sh
sh get-docker.sh

安装 Docker 十分简单，只需要等待一小会即可完成。

安装 nginx-mtproxy

拉取镜像

docker pull ellermister/nginx-mtproxy:latest

一键运行

docker run --name nginx-mtproxy -d  -p 80:80 -p 443:443 ellermister/nginx-mtproxy:latest

可通过 -p 指定端口映射，连接均为外部端口。

查看配置：

docker logs nginx-mtproxy

自定义运行

secret=$(head -c 16 /dev/urandom | xxd -ps)
tag="12345678901234567890121231231231"
domain="cloudflare.com"
docker run --name nginx-mtproxy -d -e tag="$tag" -e secret="$secret" -e domain="$domain" -p 80:80 -p 443:443 ellermister/nginx-mtproxy:latest

自定义密钥、域名和AD Tag，

Secret
secret="25c8dfee81acdadaff3a338a10db8497"
运行 head -c 16 /dev/urandom | xxd -ps 命令生成

AD Tag

tag="ashofs232975911523"

tag部分填写从官方bot处申请到的token值。

domain

domain="cloudflare.com"

Fake TLS 网址，需要填写未被防火长城认证的网址。

默认的认证页面：