Telegram 一直卡在“正在连接（Connecting...）” 在应用内部手动配置 MTProto 与 Socks5 代理

⚡ Answer-First 核心速览

Telegram 桌面端默认不会始终可靠继承 Windows 系统注册表代理，遇到 Connecting 卡死时，进入客户端【设置】->【高级】->【连接类型】，手动添加自定义代理并填入 `127.0.0.1` 及端口 `7890`（Socks5 或 HTTP）即可瞬时连通。而 Discord 语音一直卡在 RTC Connecting 或 No Route，是因为文字聊天走 TCP 而语音流强制走 UDP WebRTC 协议；必须在出海客户端中开启全局 TUN 虚拟网卡模式，并确认当前选中的代理节点支持 UDP 转发，语音通道方可成功建立。

返回故障排查与疑难杂症诊断树

在日常使用海外即时通讯工具与语音协作社区时，两个高频故障几乎困扰着每一位新手与跨国远程团队。一个是打开 Telegram（电报）桌面端或移动端，界面左下角或者顶部一直转圈显示“正在连接（Connecting...）”或者“更新中（Updating...）”，对话列表一片空白，哪怕浏览器访问外网畅行无阻，Telegram 也始终处于离线失联状态。

另一个则是打开 Discord 加入朋友的游戏开黑频道或办公语音房间时，状态栏在“正在连接（RTC Connecting）”、“ICE 正在检查（ICE Checking）”与“无路由（No Route）”之间疯狂死循环跳跃，任凭怎么重进语音房间，也听不到任何声音。

这两个故障发生在不同的应用中，但在网络协议栈层级上各自有明确的协议归属。理解 Telegram 的多数据中心（DC）长连接架构与 Discord WebRTC 语音底层的 UDP 机制，是彻底解决连接死锁的核心钥匙。

Telegram 与 Discord 通信协议层级技术拆解

为什么浏览器看视频毫无阻碍，这两个聊天软件却频繁掉线。我们需要观察它们在网络层级中各自采用的通信规范。

+-------------------------------------------------------------------------+
|                  应用协议与传输层技术对比架构                           |
+-------------------------------------------------------------------------+

[ Telegram 客户端 ]
        │
        ├── 协议类型: MTProto 协议 (基于持久化 TCP 长连接)
        ├── 寻址机制: 硬编码全球 5 大数据中心 IP 列表 (DC1 到 DC5)
        └── 代理策略: 支持应用内原生内置 Socks5 / HTTP / MTProto 代理
              │
              v
[ 发生卡死成因 ]: 系统代理仅修改浏览器注册表，Telegram 底层网络库未能自动挂接

---------------------------------------------------------------------------

[ Discord 客户端 ]
        │
        ├── 文本与信令: HTTPS + WebSocket (走 TCP 443 端口，系统代理可接管)
        │
        └── 实时语音对讲: WebRTC 媒体流传输 (强制走 UDP 协议，端口 50000 到 65535)
              │
              v
[ 发生卡死成因 ]: 系统代理模式完全无法转发 UDP 数据包，语音流直连出境遭遇物理阻断

1. Telegram 的 MTProto 协议与多数据中心（DC）

Telegram 并没有采用通用的 HTTP RESTful API 来做消息推送，而是由其创始人开发了专属的 MTProto（Mobile Transport Protocol） 移动传输协议。

Telegram 在全球部署了五个核心数据中心（Data Center，简称 DC）。

• DC1 位于美国迈阿密
• DC2 位于荷兰阿姆斯特丹
• DC3 位于美国迈阿密
• DC4 位于荷兰阿姆斯特丹
• DC5 位于新加坡

新用户注册账号时，系统会根据分配的手机号号段将用户档案锚定在某一个特定 DC 上。例如中国大陆及亚太手机号通常被分配到 DC5 新加坡，部分老账号位于 DC4 欧洲。

Telegram 客户端内部硬编码了这五个 DC 的物理 IP 地址网段。在没有外网辅助的环境下，这些 IP 网段在国内骨干网路由器上均处于 BGP 路由黑洞状态。

当您在 Windows 上启动代理软件并开启“系统代理”时，代理软件只是更改了系统的 WinINET 注册表。Telegram 桌面端基于 Qt 框架构建，其网络引擎在部分 Windows 版本或网络权限下，不会主动同步注册表代理配置。Telegram 尝试直连其硬编码的 DC 服务器 IP，数据包在出境前被直接丢弃，于是客户端只能陷入无限的 Connecting... 状态。

2. Discord 的双轨制分离 WebSocket 与 WebRTC

Discord 的架构更加特殊，它采用了文本与语音完全分离的双轨制。

• 信令与文字聊天。客户端渲染用户界面、收发文字消息、加载表情包与频道列表时，使用的是标准的 HTTPS 与基于 TCP 的 WebSocket（网关位于 gateway.discord.gg）。这一部分流量只要开启了常规系统代理，就能正常流通。
• 实时语音频道（Voice Channel）。当您点击加入语音频道的瞬间，Discord 会向语音网关发起协商，并立刻切换为 WebRTC 协议。WebRTC 为了保证语音的超低延迟与无卡顿交互，强制使用无连接的 UDP 协议 传输 Opus 编码的音频帧。

常规的系统代理（HTTP 代理）只在第七层（应用层）工作，根本不具备转发第四层 UDP 数据报文的能力。

当您开启普通系统代理加入 Discord 语音时，文字部分走通了代理，但语音流的 UDP 数据包依然被强行丢向物理网卡直连远端语音服务器。由于 Discord 语音机房大多位于海外且受到网络阻断，UDP 数据包有去无回，WebRTC 握手彻底失败，客户端便只能在 RTC Connecting、ICE Checking 与 No Route 之间死循环卡死。

典型连接故障与排查处置大表

下表汇集了出海运维实践中关于 Telegram 与 Discord 的十种最高频连接故障表现、对应诊断指标与推荐处置方案。

故障现象分类	客户端典型报错提示	影响范围	根本故障机制深度剖析	推荐工程处理手段
Telegram 未继承代理	左下角持续显示 Connecting...	桌面端全功能不可用	Qt 网络引擎未读取 Windows 注册表代理	在 Telegram 设置中手动添加本地 127.0.0.1 代理
Telegram 开启 IPv6 干扰	长期停留 Updating... 列表不刷新	桌面端与手机端同时出现	运营商下发了无外网出海能力的劣质 IPv6	在客户端连接设置中关闭通过 IPv6 连接选项
Telegram 移动端收不到验证码	发送短信倒计时结束后无反应	iOS / Android 手机端	官方为了防欺诈限制了受阻网络下的 SMS 下发	改用已登录设备接收应用内验证码或切换网络
Discord 语音通道 RTC 卡死	状态栏持续显示 RTC Connecting	无法听到声音且麦克风失效	语音 WebRTC 依赖 UDP，系统代理无法接管	开启客户端 TUN 虚拟网卡模式接管 UDP 数据包
Discord ICE 握手失败	频繁弹窗 ICE Checking 后红字断开	语音房间建立连接中断	STUN 服务器探测失败，无法协商内网穿透端口	检查节点分流规则，确保 Discord 域名走代理
Discord 提示 No Route	状态栏直接报 No Route（无路由）	语音通道彻底被掐断	代理节点本身不支持 UDP 转发（UDP Relay 关闭）	在节点列表中换用明确标注支持 UDP 的优质专线
代理软件分流规则漏掉 DC	Telegram 偶发性卡死，换节点又正常	部分特定群组与媒体加载卡死	分流规则缺少 Telegram 特定 DC 的 IP CIDR	更新客户端分流规则集，引入完整的 Telegram 规则
机场封禁特定语音端口	Discord 文字正常，语音延迟高达 5000ms	声音严重断续撕裂变电音	机场为了防止 BT 下载屏蔽了高位 UDP 端口	切换至不封锁 UDP 的非中转直连或游戏专线节点
局域网防火墙阻断回环	填了 127.0.0.1 依然连不上	任何应用内代理设置无效	本地安全防护软件阻断了应用跨进程回环连接	将 Telegram 与代理客户端加入 Windows 防火墙信任
Discord 语音子系统兼容冲突	绿色已连通（Connected）但无声音	听不到别人且别人听不到自己	Windows 驱动与 Discord 默认音频子系统冲突	在 Discord 语音设置中将音频子系统切换为 Legacy

Telegram 应用内部手动挂接代理配置实战

解决 Telegram 连接卡死最直接、最稳妥的方法，就是在其软件内部显式指定代理参数，不再依赖操作系统的弱契约自动探测。

[ Telegram 内部代理配置流转 ]
进入 Telegram 界面
       │
       ▼
点击左上角三道杠菜单 ──> 进入【Settings (设置)】
       │
       ▼
点击进入【Advanced (高级)】选项
       │
       ▼
找到第一项【Connection type (连接类型)】
       │
       ├── 默认状态: Default (use system proxy) ──> [容易失效卡死]
       │
       └── 点击选择: Use custom proxy (使用自定义代理)
                 │
                 ├── 方案 1: SOCKS5 代理 (推荐)
                 │     ├── Host: 127.0.0.1
                 │     └── Port: 7890 (与代理客户端保持一致)
                 │
                 ├── 方案 2: HTTP 代理
                 │     ├── Host: 127.0.0.1
                 │     └── Port: 7890
                 │
                 └── 方案 3: MTProto 专属代理 (Fake TLS 混淆)
                       ├── Server: 代理服务器域名或 IP
                       ├── Port: 443
                       └── Secret: 带 ee 前缀的十六进制伪装密钥

1. Windows 与 macOS 桌面端配置步骤

1. 打开 Telegram 桌面客户端。如果界面一直转圈，直接点击左上角的三条横线展开主菜单。
2. 点击 Settings（设置） 图标进入设置中心。
3. 在选项列表中找到并点击 Advanced（高级）。
4. 在最顶部的 Data and storage（数据与存储） 下方，点击 Connection type（连接类型）。
5. 界面默认勾选的是 Default (use system proxy)。点击下方的 Add proxy（添加代理）。
6. 在代理协议类型中，勾选 SOCKS5（或者 HTTP 均可）。
7. 参数填写规范。
   • Socket address（主机地址） 填入本地回环地址 127.0.0.1。
   • Port（端口） 填入您本地代理客户端的混合端口或 Socks5 端口。通常 Clash Verge、Mihomo Party 默认为 7890，v2rayN 默认为 10808。
   • Username 与 Password（用户名与密码） 留空不填。
8. 点击右下角 Save（保存）。
9. 回到连接列表，将刚才添加的代理项状态切换为勾选激活。

在保存后的两秒钟之内，您会看到该代理条目下方出现绿色字样的在线延迟（例如 online, 45 ms），左下角的转圈提示瞬间变为“已连接”，群组消息与未读气泡即可秒级刷新出来。

2. MTProto 专属代理进阶与 Fake TLS 伪装机制

除了使用本地回环 SOCKS5 端口，Telegram 还原生支持一种专属的 MTProto Proxy 协议。

很多用户在 Telegram 频道中看到一键连接链接形如 tg://proxy?server=...&port=443&secret=...。 早期的 MTProto 代理由于传输特征明显，极容易被深度包检测（DPI）设备识别并瞬间封禁 IP。现代成熟的 MTProto 代理广泛引入了 Fake TLS 伪装机制。

在配置参数中，密钥（Secret）通常以 ee 作为前缀，后面拼接 32 位的十六进制散列，并在末尾附加伪装域名（如 cloudflare.com 或 bing.com）。 当客户端向远端 MTProto 代理服务器发起握手时，发出的第一个数据包完全被封装成一个标准的 TLS Client Hello 握手报文，握手报文中的 SNI 域名赫然指向知名的国际安全 CDN。沿途防火墙设备将其误判为普通的合法网站访问予以放行，数据包到达服务端后才被真正剥离还原出 Telegram 数据。在缺少本地代理客户端的环境下，配置带 Fake TLS 的 MTProto 代理能够提供极强的直通韧性。

3. 关键排错细节 关闭通过 IPv6 连接

在同一个连接设置页面下方，有一项名为 Try connecting through IPv6（尝试通过 IPv6 连接） 的开关。

强烈建议将该开关彻底保持关闭。

当前国内大部分家庭宽带虽然分配了公网 IPv6 地址，但许多城域网或省际出口在处理通往境外的 IPv6 路由时丢包率极高，甚至压根没有国际 IPv6 对等互联。如果开启了该选项，Telegram 会优先尝试使用劣质的 IPv6 链路直连新加坡或欧洲数据中心，导致原本正常的连接再次陷入周期性卡死与假死。

Discord 语音 RTC Connecting 终极修复 开启 TUN 模式与 UDP 联动

如果说 Telegram 只要在软件内填个端口就能搞定，那么 Discord 语音频道的问题则必须深入到操作系统底层协议栈去解决。

前面已经讲过，Discord 语音走的是 UDP 协议。普通的 HTTP 代理软件无论怎么设置应用内代理，也无法拯救 Discord 的语音 WebRTC 握手。彻底修复该问题的工业级解法是开启 TUN 虚拟网卡模式。

[ Discord 语音加入与流量接管流水线 ]
用户点击加入 Discord 语音房间
       │
       ▼
发起 WebSockets 握手 (走代理 TCP，显示 RTC Connecting)
       │
       ▼
协商远端语音服务器 IP 与 UDP 高位端口 (例如 162.159.x.x:54321)
       │
       ▼
操作系统发出原始 UDP 媒体流数据报文
       │
       ├── 分支 A: 未开启 TUN 模式 (仅普通系统代理)
       │     └── 报文落入物理网卡直连出海 ──> 被防火墙丢弃 ──> [死锁在 No Route]
       │
       └── 分支 B: 已正确开启 TUN 虚拟网卡模式 (Wintun 驱动接管)
             │
             ▼
       内核路由表将 UDP 数据包直接捕获并投递进虚拟网卡
             │
             ▼
       代理客户端核心将 UDP 报文打包装入加密隧道 (UDP Relay)
             │
             ▼
       到达境外低延迟代理节点，由落地机房与 Discord 语音服务器建立对讲
             │
             ▼
       状态栏瞬间跳绿显示【Voice Connected (语音已连接)】

1. 深入剖析 WebRTC ICE 候选探测与状态机

在点击进入 Discord 语音频道后，状态栏之所以会经历复杂的字样跳变，是因为 WebRTC 协议正在执行严格的对等连接建立流程。

1. Gathering（收集阶段）。Discord 客户端通过 STUN 协议探测自身位于公网的映射 IP 与端口，生成一系列候选地址（Candidate）。
2. Checking（检查阶段，对应 ICE Checking）。客户端开始尝试向 Discord 分配的语音边缘网关（Voice Gateway）发送 UDP 绑定测试请求。如果在这一阶段，连续发送多个 UDP 探测包均没有收到对端的回应，握手流程便陷入停滞。
3. Connected（已连通）或 Failed（失败，对应 No Route）。在尝试超时（通常为 15 秒）后，状态机判断无可用路由，最终直接弹出断开错误。

由此可见，如果出海网络无法承载双向 UDP 报文的畅通穿透，WebRTC 的状态机就永远无法推向 Connected 阶段。

2. 确认代理节点具备 UDP 转发能力

这是排查的第一要务。如果代理服务商为了节约服务器带宽或防范 DDOS 攻击，在服务端关闭了 UDP 转发（UDP Relay），那么无论本地怎么配置 TUN 模式，UDP 数据包都无法通过隧道传输。

在 Clash Verge Rev 或 Sing-box 客户端中，查看节点详情。

• 在节点配置 YAML 中，该节点必须声明包含 udp: true。
• 如果客户端提供节点测速功能，观察是否有专门的 UDP 类型测试，确保延迟能够正常返回。

3. 开启并配置 TUN 虚拟网卡模式

在现代出海客户端（如 Clash Verge Rev、Mihomo Party）中，开启 TUN 模式只需几个关键动作。

1. 安装核心服务模式（Service Mode）。TUN 虚拟网卡需要在操作系统内核中注入驱动，属于高特权操作。在客户端通用设置中，找到服务模式，点击安装。安装成功后，服务模式旁边会亮起绿色对勾图标。
2. 启用 TUN 模式开关。在客户端主界面勾选 TUN 模式（TUN Mode）。此时 Windows 系统中会自动生成一张名为 wintun 的高速虚拟网卡。
3. 协议栈选择 gVisor 或 System。在内核高级设置中，将 TUN 协议栈模式优先设置为 gvisor。gVisor 是由 Google 开源的用户态网络栈，对 UDP 报文的重组与碎片整理具备极高的容错性，能够有效杜绝 Discord 语音频繁丢包爆音的现象。

4. 配置分流规则确保 Discord 走代理

在客户端的分流规则配置中，确保 Discord 的域名与语音服务器未被误判为 Direct（直连）。一个标准的规则配置段应当包含以下条目。

rules:
  # Discord 核心域名走代理
  - DOMAIN-SUFFIX,discord.gg,PROXY
  - DOMAIN-SUFFIX,discord.com,PROXY
  - DOMAIN-SUFFIX,discordapp.com,PROXY
  - DOMAIN-SUFFIX,discordapp.net,PROXY
  - DOMAIN-KEYWORD,discord,PROXY
  # 兜底出海策略
  - MATCH,PROXY

开启 TUN 模式后，再次进入 Discord 点击加入语音频道，您会看到状态栏在跳过短暂的 RTC Connecting 后，直接跳过漫长等待，变为鲜艳的绿色字样 Voice Connected（语音已连接），ping 值稳定显示在 50ms 到 80ms 之间，麦克风对讲恢复顺畅。

自动化连通性探测脚本编写

为了在出现连接故障时迅速定位是本地端口未开、Telegram 数据中心受阻还是 Discord 语音节点失联，编写了一个实用的 PowerShell 诊断脚本。

将以下代码保存为 check_im_connectivity.ps1。

Write-Host "==========================================================" -ForegroundColor Cyan
Write-Host "     Telegram 与 Discord 跨国即时通讯网络连通性自动化诊断    " -ForegroundColor Cyan
Write-Host "==========================================================" -ForegroundColor Cyan
Write-Host ""

# 1. 检测本地代理端口监听状态
$localPort = 7890
Write-Host "[1/3] 正在检测本地回环代理端口 $localPort 监听状态..." -ForegroundColor Yellow
$portCheck = Get-NetTCPConnection -LocalPort $localPort -State Listen -ErrorAction SilentlyContinue

if ($portCheck) {
    Write-Host "      [✓] 本地代理端口 $localPort 正在正常监听中" -ForegroundColor Green
} else {
    Write-Host "      [x] 未检测到 $localPort 端口监听！请确认代理客户端是否已启动！" -ForegroundColor Red
}

# 2. 探测 Telegram 核心数据中心 IP 连通性
Write-Host ""
Write-Host "[2/3] 正在探测 Telegram 亚太 (DC5) 与欧洲 (DC4) 数据中心直连状态..." -ForegroundColor Yellow

# DC5 新加坡 IP 与 DC4 荷兰 IP
$tgDcs = @(
    @{ Name = "Telegram DC5 (亚太-新加坡)"; IP = "91.108.56.172"; Port = 443 },
    @{ Name = "Telegram DC4 (欧洲-阿姆斯特丹)"; IP = "149.154.167.91"; Port = 443 }
)

foreach ($dc in $tgDcs) {
    $t = Test-NetConnection -ComputerName $dc.IP -Port $dc.Port -WarningAction SilentlyContinue
    if ($t.TcpTestSucceeded) {
        Write-Host "      [✓] $($dc.Name) 物理 TCP 握手成功 (延迟: $($t.PingReplyDetails.RoundtripTime) ms)" -ForegroundColor Green
    } else {
        Write-Host "      [!] $($dc.Name) 直连握手失败 (符合预期，必须依赖代理转发)" -ForegroundColor DarkGray
    }
}

# 3. 探测 Discord 信令网关与 WebRTC 边缘节点
Write-Host ""
Write-Host "[3/3] 正在探测 Discord 信令与语音边缘网关连通性..." -ForegroundColor Yellow
$discordHosts = @("gateway.discord.gg", "voice.discord.gg")

foreach ($dh in $discordHosts) {
    try {
        $ip = [System.Net.Dns]::GetHostAddresses($dh)[0].IPAddressToString
        Write-Host "      [*] 解析域名 $dh -> IP: $ip" -ForegroundColor Cyan
        $dt = Test-NetConnection -ComputerName $ip -Port 443 -WarningAction SilentlyContinue
        if ($dt.TcpTestSucceeded) {
            Write-Host "          [✓] $dh TCP 握手就绪！" -ForegroundColor Green
        } else {
            Write-Host "          [x] $dh 握手受阻，请检查出海代理规则！" -ForegroundColor Red
        }
    } catch {
        Write-Host "      [x] 域名 $dh 解析失败，遭遇本地 DNS 污染！" -ForegroundColor Red
    }
}

Write-Host ""
Write-Host "====================== 排错结论指引 ======================" -ForegroundColor Cyan
Write-Host " 1. 若 Telegram 卡 Connecting: 在应用内填入 127.0.0.1:7890 即可。"
Write-Host " 2. 若 Discord 卡 RTC Connecting: 必须在客户端开启 TUN 模式且节点支持 UDP。"
Write-Host "==========================================================" -ForegroundColor Cyan

以管理员身份运行该脚本，即可迅速明确本地网络链路上是哪一个环节出现了阻断。

常见疑难故障排查与 FAQ 问答

在处置 Telegram 与 Discord 网络问题时，以下四个场景极为典型。

1. Telegram 手机端（iOS/Android）怎么配置代理？

与桌面端类似，手机端同样原生支持内部代理。

• 打开手机端 Telegram，点击右下角 Settings（设置）。
• 进入 Data and Storage（数据与存储）。
• 滑动到最下方，点击 Proxy Settings（代理设置）。
• 点击 Add Proxy（添加代理），即可添加 Socks5 或 MTProto 代理。如果手机连接了家庭 Wi-Fi，且电脑开启了局域网代理共享，可以在主机名处填写电脑的局域网 IP（如 192.168.1.100）和端口 7890，实现手机无需装客户端直接出海。

2. 为什么在 Discord 开启了 TUN 模式，语音依旧显示 No Route？

出现该现象通常有两个隐蔽诱因。

• 杀毒软件防火墙拦截了 Wintun 驱动。部分第三方安全防护软件（如火绒、360 等）的流量监控模块会强行过滤虚拟网卡吐出的 UDP 报文，导致报文无法封装发出。可尝试临时退出第三方杀软排查。
• Discord 语音节点处于长连接僵死状态。在某些情况下，旧的连接句柄残留在 Discord 内存中。在开启 TUN 模式后，完全关闭 Discord 进程（在任务栏托盘右键退出并重新打开），重新加入语音频道即可建立新的干净连接。

3. Telegram 经常自动掉线提示 Connecting，过十几秒又恢复是怎么回事？

这通常是因为出海节点服务器与 Telegram 数据中心之间的 TCP 长连接被中间网络防火墙重置，或者是客户端使用的节点在晚高峰发生了剧烈丢包。

在 Telegram 的高级设置中，将代理类型由 HTTP 更改为 SOCKS5 协议，能够显著提高长连接的心跳稳定性；同时在代理客户端中为 Telegram 配置专用的低延迟、不超售专线节点，可以彻底告别频繁掉线。

4. Discord 语音对讲时，别人听我断断续续，像机器人机械音是怎么回事？

这是典型的出境 UDP 数据包丢包与抖动（Jitter）现象。 Opus 语音编码在丢包率超过 10% 时，音频补偿算法无法脑补出丢失的声音帧，就会产生严重的失真撕裂。

处置建议。

• 严禁使用普通公网直连节点进入 Discord 语音，务必换用延迟在 60ms 以内的 IPLC 内网专线节点。
• 在 Discord 用户设置 -> 语音与视频 中，找到 服务质量高数据包优先级（QoS），尝试将其关闭。国内部分家用路由器在处理标记了 DSCP 高优先级的 UDP 数据包时反而会进行限速丢弃。