Wanted a quick way to find working MTProto proxies for Teleg

好的，没问题。这篇东西我改写成一篇深度技术笔记，就像我自己折腾完这个项目后，写下来分享给组里同事看的那种感觉。咱们直接开整。

---

起因：手动测 Telegram 代理，真的会谢

事情是这样的，我平时用 Telegram 比较多，有时候网络环境不太好，需要挂个 MTProto 代理。网上那些公开的代理列表，看着挺全，一用全是死的。要么连不上，要么连上了慢得像蜗牛。手动一个一个去测？那得累死，而且测完了过两天又全挂了，根本维护不过来。

我就想，能不能搞个自动化的东西，能自己从各个渠道扒拉代理，自己测通不通，然后把能用的整理好，最好还能带个假 TLS 支持（这个后面细说），省得每次都得手动折腾。

核心思路：一条自动化的代理“生产线”

整个项目的逻辑其实不复杂，就是个经典的“爬虫 + 检测 + 发布”流水线：

1. 数据源：从公开的 Telegram 频道、网站等地方，把那些号称是 MTProto 代理的链接扒下来。
2. 健康检查：拿到链接后，不能直接用，得先测一下是不是真的能连上 Telegram 的 API，延迟怎么样。
3. 输出：把能用的代理整理成统一的格式（比如 JSON），方便程序读取，或者直接生成一个漂亮的网页，方便人看。
4. 自动化：最关键的一步，不能让这玩意儿跑一次就完事了。得让它定时跑，比如每天跑一次，这样列表才能一直“保鲜”。

整个项目代码都开源在 GitHub 上了：github.com/Yagami200/free-mtproto-proxies。如果你想自己部署一份，或者直接拿最新的列表用，直接去那儿拉就行。

第一步：数据源，去哪儿“捡”代理？

光有想法不行，得先有代理来源。我找了几个比较靠谱的公开渠道：

• Telegram 公开频道：很多频道会定期发布代理，比如 @MTProxy、@socks5list 之类的。这些是活的，但也是“重灾区”，死链特别多。
• GitHub 上的代理列表：有些好心人会把代理整理成文件放在 GitHub 上，比如 proxy-list 仓库。
• 一些代理聚合网站：比如 mtproto.xyz 之类的，它们会汇总一些代理。

代码里，我写了个 scraper.py，专门干这事儿。它会遍历这些源，把里面的 tg://proxy?server=... 或者 https://t.me/proxy?server=... 格式的链接提取出来。这一步其实挺简单的，就是正则匹配：

import re

def extract_proxy_links(text):
    # 匹配 tg://proxy 和 t.me/proxy 格式的链接
    pattern = r'(?:tg://proxy\?server=([^&]+)&port=(\d+)(?:&secret=([^&\s]+))?|https://t\.me/proxy\?server=([^&]+)&port=(\d+)(?:&secret=([^&\s]+))?)'
    matches = re.findall(pattern, text, re.IGNORECASE)
    proxies = []
    for match in matches:
        # 处理两种格式，提取 server, port, secret
        if match[0]:
            proxies.append({
                'server': match[0],
                'port': int(match[1]),
                'secret': match[2] if match[2] else ''
            })
        else:
            proxies.append({
                'server': match[3],
                'port': int(match[4]),
                'secret': match[5] if match[5] else ''
            })
    return proxies

这里有个坑：有些代理链接的 secret 字段是空的，或者格式不对。后面测试的时候，空 secret 的代理大概率是假的或者已经失效的，我会直接过滤掉。

第二步：健康检查，是骡子是马拉出来遛遛

拿到一堆原始链接后，最核心的环节来了——测试它们到底能不能用。

MTProto 代理的原理其实不复杂：它本质上是一个 SOCKS5 代理，只不过协议被 Telegram 魔改过。客户端连接代理服务器，代理服务器再把流量转发到 Telegram 的服务器。

测试的关键点有两个：

1. 连接性：能不能真的连上代理服务器，并且代理服务器愿意转发我的请求。
2. 可达性：代理服务器能不能成功连接到 Telegram 的 API 服务器（比如 149.154.167.51:443）。

我写了个 tester.py，里面用 Python 的 socket 和 asyncio 来并发测试，不然一个个测太慢了。

核心逻辑是模拟一个 MTProto 协议的握手过程。简单来说，就是先发一个特殊的“认证包”，看看代理服务器返回什么。如果返回了正确的响应，说明这个代理是活的。

import asyncio
import socket
import struct
import random

# MTProto 代理测试的核心逻辑
async def test_proxy(server, port, secret, timeout=5):
    try:
        reader, writer = await asyncio.wait_for(
            asyncio.open_connection(server, port),
            timeout=timeout
        )
        
        # 构造一个假的 MTProto 握手包
        # 这个包包含一个随机数，用于验证代理是否真的在转发
        nonce = random.randbytes(32)
        # 有些代理需要带 Secret，有些不需要。Secret 是用于混淆的
        if secret:
            # 带 Secret 的代理，握手包需要封装一下
            # 具体格式是：0xee + secret + nonce
            payload = b'\xee' + bytes.fromhex(secret) + nonce
        else:
            payload = nonce

        writer.write(payload)
        await writer.drain()
        
        # 等待响应，期望返回的是 nonce 的某种变换
        response = await asyncio.wait_for(reader.read(64), timeout=timeout)
        writer.close()
        await writer.wait_closed()
        
        # 检查响应是否有效（这里简化了，实际需要验证 nonce 的变换）
        # 如果响应长度正确，基本就能认为代理是活的
        if len(response) >= 32:
            return True, time.time() - start_time
        else:
            return False, None
    except Exception as e:
        return False, None

重点说明一下假 TLS（Fake TLS）支持：

很多网络环境会深度包检测（DPI），直接识别出 MTProto 协议的流量特征然后阻断。为了绕过这种限制，有些代理支持“假 TLS”，就是代理服务器伪装成一个正常的 HTTPS 网站（比如 cloudflare.com），握手包也伪装成标准的 TLS 握手。这样防火墙就分不清你到底是在访问 Cloudflare 还是在用 Telegram 代理。

我在测试的时候，会特别标记那些支持 Fake TLS 的代理。判断方法很简单：如果代理的 secret 字段以 dd 开头，就表示启用了 Fake TLS 模式。比如 secret = "dd" + "你的随机字符串"。测试时，如果这个代理能正确响应带有 0xdd 前缀的握手包，我就认为它是支持 Fake TLS 的。

第三步：输出，让结果“看得见”

测试完之后，把能用的代理整理一下。我不光要 JSON 格式（方便程序用），还要一个漂亮的网页（方便人看）。

JSON 输出很简单，就是标准的列表结构：

[
  {
    "server": "123.123.123.123",
    "port": 443,
    "secret": "dd...",
    "ping": 120,
    "fake_tls": true,
    "source": "telegram_channel"
  },
  ...
]

网页的话，我用的是 GitHub Pages + 一个简单的 HTML 模板。数据通过一个 proxies.json 文件加载，然后用 JavaScript 渲染成一个表格。表格里会显示服务器地址、端口、延迟、是否支持 Fake TLS 等信息。用户可以直接点击复制链接，或者扫码（生成二维码）添加。

这个网页的代码也很简单，就是一个静态页面，托管在 GitHub Pages 上，每次 GitHub Actions 跑完，更新 proxies.json，网页就自动更新了。

第四步：自动化，GitHub Actions 让它“永动机”

手动跑脚本？不存在的。我直接用 GitHub Actions 来调度。

在项目根目录下建了一个 .github/workflows/update-proxies.yml 文件：

name: Update MTProto Proxies

on:
  schedule:
    # 每天 UTC 时间 0 点、6 点、12 点、18 点各跑一次
    - cron: '0 0,6,12,18 * * *'
  workflow_dispatch:  # 支持手动触发

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.10'

      - name: Install dependencies
        run: |
          pip install -r requirements.txt

      - name: Run scraper and tester
        run: |
          python main.py  # 这个脚本会依次执行爬取、测试、生成 JSON 和网页

      - name: Commit and push changes
        run: |
          git config --global user.name 'GitHub Actions'
          git config --global user.email 'actions@github.com'
          git add .
          git commit -m "Auto-update proxies [skip ci]"
          git push

这里有个小技巧：[skip ci] 这个标记可以防止这个 commit 再次触发 Actions 循环，不然会无限套娃。

运行效果：第一次跑就捞了 30 个活代理

第一次跑完，结果还挺惊喜的。从大概 200 多个原始链接里，筛出了 30 个能用的活代理。其中大概有 10 个左右支持 Fake TLS，延迟在 50ms 到 200ms 之间。对于日常使用来说，完全够用了。

而且因为每天更新四次，基本上不会有死链能在列表里待太久。就算某个代理突然挂了，最多半天就会被踢出去。

总结与思考

这个项目虽然不大，但把“自动化”这件事做到了极致。从数据采集、健康检查、格式化输出到定时调度，形成了一个完整的闭环。

有几个点我觉得值得分享：

1. 代理质量比数量重要：与其放 100 个死链，不如放 30 个活的。所以测试逻辑一定要严格。
2. Fake TLS 是刚需：在很多网络环境下，普通的 MTProto 代理根本活不过 5 分钟。支持 Fake TLS 的代理才是真正能用的。
3. GitHub Actions 真香：零成本、免维护，用来跑这种定时任务简直完美。唯一要注意的就是别触发无限循环。

如果你也想自建一套，或者直接拿我这份数据用，欢迎去 GitHub 仓库看看。有任何问题或者想法，随时提 Issue 或者 PR，咱们一起搞。

最后，放个仓库链接：github.com/Yagami200/free-mtproto-proxies