Telegram 在 Clash 下總顯示「正在連接」？補全 t.me 與 MTProto 分流（2026）

先釐清症狀：不是「沒有網路」，而是「路徑沒有對齊」

許多使用者在關鍵字裡寫 Telegram 正在連接代理、或 Clash Telegram 分流 時，真實狀況常是：瀏覽器、其他 App 都能透過節點出網，但 Telegram 桌面版或行動版卻在啟動畫面、登入前驗證、或帳戶剛載入時一直顯示「正在連接」。這與單一網址被防火牆攔下不完全相同，而是一組分散在多個主機名與傳輸層的依賴沒有在 Clash 的同一套規則決策內被一起帶上代理。

Telegram 的技術棧可粗分為兩大塊。其一是你可透過瀏覽器辨識的 HTTPS 入口：短連結 t.me、官網、說明文件、部分 OAuth 相關頁面。其二是行動與桌面客戶端在背景維持帳戶、訊息與 MTProto 所仰賴的 API、CDN、資料中心（DC）協商與切換。只把其中一邊的網域寫進規則，卻讓其餘連線在 GEOIP 或寬泛預設策略裡被提前收斂，就會變成你「以為有開代理」、實務上卻是關鍵控制連線仍走直連或錯節點，介面就卡在連線中。本文以繁體中文與臺灣讀者習慣用語整理可複製的排查順序，並明確與本站Discord 的 UDP 語音導向文、以及以長連線為主的 IDE 分流文作出區隔：Telegram 在一般聊天場景以 MTProto over TCP 443 等常見模式 為主，關鍵是主機名覆蓋與策略一致，不必先把它當成與遊戲語音同級的純 UDP 專案——除非你另外啟用通話且環境有阻擋。

t.me 與入口層：短網址、登入前跳轉與靜態資源

使用者從外站點到 Telegram，最常遇到的是 t.me 相關短網址與帳戶、頻道、機器人的導向流程。此類請求在 Clash 日誌裡通常以 DOMAIN-SUFFIX 針對 t.me 即可涵蓋大多數轉址；但實務上還要留意跳轉鏈中是否夾帶 telegram.org 子域、或登入與內容載入所依賴的 api.telegram.org 等主機名。若你的規則只寫了短網址、卻在更前面被一條「地區分流的直連」攔下 API，客戶端就會在 UI 上呈現持續連線、或反覆重試卻不給明確錯誤碼。

寫法上建議把「Telegram 產品線」視作單一策略意圖：例如 TELEGRAM 策略組內手動或自動選定節點，並讓 DOMAIN-SUFFIX,t.me,TELEGRAM、DOMAIN-SUFFIX,telegram.org,TELEGRAM 等行放在寬泛地理規則之前。關鍵在序位，而不是蒐集一份永不更新的「全網域表」。實作時應以你客戶端實際連線預覽中出現的主機名為準，逐步補；網上複製的長清單若與你訂閱或核心版本衝突，反而會在更新訂閱時整批蓋掉手動行，務必留意匯入工具的合併邏輯。

MTProto 與資料中心：為什麼要單獨談一塊？

MTProto 是 Telegram 客戶端與伺服器之間的主要通訊協定。客戶端會在可用連線之間做協商、必要時在資料中心之間遷移；你在 Clash 內要處理的不是「一個靜態 IP」，而是一組會隨產品與網路狀況變化的端點與 SNI 型態的組合。搜尋 MTProto 規則 的使用者，多半已察覺：僅有 HTTP 測通、或只代理瀏覽器，不足以讓行動與桌面客戶端在背景完成 DC 測試與長連線。若 MTProto 相關主機名或對應 IP 行為沒有與你為 Telegram 所設的策略組一致，就會在介面上呈現我們在開頭描述的長時間 Telegram 正在連接代理 卻不成功的狀況。

與 MTProto 代理（使用者手動在客戶端內額外填寫的 SOCKS5／MTProto 轉送）要區分：本文聚焦於系統層與 Clash 規則讓本機客戶端直連到 Telegram 公網端點的情境。若你同時在 Telegram 內再套一層 MTProxy，路徑會變成雙層，除錯時應關掉其中一層對照。對多數讀者而言，先把 Clash 的策略一致化跑通，再考慮是否要在應用內額外指定 MTProxy。

規則順序與 `GEOIP`：別讓「捷徑」比 Telegram 專用行更早成立

在 Clash Telegram 分流 實作裡，最常見的錯誤是匯入一份以國內外分流為主的大型規則庫，其中 GEOIP,CN,DIRECT 或類似捷徑位於自訂網域之前。Telegram 相關端點的 IP 可能落在讓人意想不到的地理區塊，或與你預期相反；一條寬泛捷徑若先被命中，就會讓你為 Telegram 寫的 DOMAIN-SUFFIX 根本沒有機會執行。修正方向很單純：把產品專屬的 mtproto 規則邏輯（實作上還是表達為針對已知後綴與觀測到之主機名）上移，或在地理捷徑上加註、分段維護，確保不會在不知情的情況下被第三方規則集覆寫。

若你剛接觸 proxy-groups 與 rules 的寫法，建議先讀Clash YAML 配置深度解析，再回來把 Telegram 當成「需要完整覆蓋登入＋主連線」的產品，而不是兩行關鍵字即可收工。寫規則時在檔內用英文註解保留「為什麼要把它放在 GEOIP 前面」的備註，也會在半年後的你自己感謝現在的你。

系統代理、`mixed-port` 與 TUN：何時要開整機轉發？

只依賴 系統 HTTP／HTTPS 代理 時，行為良好的桌面程式會把部分 TLS 走代理，但並非所有 Telegram 實作都願意把每一條與登入、DC 偵測有關的連線，完整交給系統代理層。相對地，TUN 或作業系統層的虛擬介面攔截，讓多數程式的 TCP 443 等流量一併納入 Clash 的規則表，能顯著降低「同一台機器、瀏覽器正常、單一 App 一直轉圈」的機率。缺點則是易與其他 VPN、公司零信任、或自架路由產生路由表衝突。若你開 TUN 後出現斷網、或只有部分網路可用，應先依Windows TUN 與防火牆排查文處理基底環境，再回頭看 Telegram 是否真的仍缺網域。

從讀者提問的「要不要開埠」角度整理：一般不需另外為 MTProto 手動開一組神秘埠。客戶端多數以常見的 TLS 埠（例如 443）與伺服器協商；關鍵是路徑是否經過 Clash 的規則引擎、以及 節點是否允許該類型長連線與轉送。若你使用站方提供的 Web 版 或內建瀏覽器元件，還要一併檢查是否與桌面主程式分屬不同可執行檔或沙箱，兩邊的系統代理感知能力可能不同。

DNS、`fake-ip` 與主機名在「看起來解析成功」卻不連線的落差

在 Fake-IP 模式下，若 Telegram 所依賴的某個主機名被錯誤歸戶、或要列入 fake-ip-filter 才與實連線行為一致，就會出現「解析畫面正常、實際連線卻反覆中斷」的現象。本站文件頁的 DNS 與 Fake-IP 說明從核心機制解釋了常見行為；落實在 Telegram 上，建議在除錯階段關閉多餘的上游測速與積極的 DNS 分岔，先讓一組穩定上游與一組清晰規則跑通，再考慮進階分流。

設定檔概念範例：策略組＋靠前網域行（還請改寫為實測日誌）

以下為 示意用 YAML，策略組名稱、節點與網域行請務必以你的訂閱、核心版本、以及連線預覽內實際出現的主機名替換。合併前請先備份。

proxy-groups:
  - name: TELEGRAM
    type: select
    proxies:
      - YOUR_NODE
      - DIRECT

rules:
  # Public suffix examples — expand from your own connection log
  - DOMAIN-SUFFIX,t.me,TELEGRAM
  - DOMAIN-SUFFIX,telegram.org,TELEGRAM
  - DOMAIN-SUFFIX,telegra.ph,TELEGRAM
  - DOMAIN,api.telegram.org,TELEGRAM
  # If using curated RULE-SET, keep Telegram-related sets above wide GEOIP blocks

若你使用 RULE-SET 與 GEOSITE 類型來源，仍可沿用同一邏輯：把能涵蓋 Telegram 或即時通訊品類的集合，放在寬泛地理或預設 MATCH 之前，並在匯入工具裡關注行順序在更新前後是否被重排。寫的是 MTProto 規則 的意圖，落實在設定檔裡則是清楚可讀的網域與集合管理。

驗收：用固定步驟對照日誌，一次只改一個變因

建議的驗收流程是：先完全關閉再開啟客戶端，觀察從啟動到帳戶就緒之間的每一個新主機名；再進入一個對話、傳一則小訊息、觸發圖片或附件，補上 CDN 相關名稱。每一輪只調整一項（例如只動規則序、或只切 TUN 開關），否則你會在「TUN 與訂閱內邏輯同時在變」下難以判讀。若你固定同一節點後，Telegram 正在連接代理 症狀消失，但換成自動選節點又復發，就該改檢查測速與容錯切換是否對長連線不友善，而非懷疑 t.me 寫錯單一筆。

症狀對照（仍以實際日誌為準）

下表幫你快速把現象分桶；細節仍須以連線日誌與節點商業條件為主。

你看到的狀況	較常見原因	可優先處理的方向
瀏覽器開 t.me 正常、App 一直「正在連接」	系統代理未涵蓋 App 全路徑，或 `GEOIP` 先於 Telegram 專用行	改 TUN 或校準規則序；在日誌中比對主機名
有時能登入、有時卡在歡迎畫面	多上游 DNS 與策略決策脫節、或節點在切換	精簡 DNS 設定、語音通話前暫改手動固定節點
僅圖片與大檔異常、文字尚可	附件 CDN 與主連線採不同主機名	在連線預覽中補滿附件所用到之後綴或規則集
開 TUN 後全機斷網	路由、防火牆、或他牌 VPN 疊加	參考 TUN 專文；避免多層攔截同時實驗
同節點他站正常、僅 Telegram 失敗	節點對目標地區之連線品質、或產品線未完整命中	更換地區、仍以日誌補齊未命中之網域

合規與服務條款

使用代理或第三方節點存取 Telegram 等服務，仍受各服務條款、節點商政策、以及你所在地法律規範。本文僅從網路代理與用戶端行為的技術角度，說明 Clash 規則層的常見處理方式，請讀者自行判斷合規性。

結語

要解決在 Clash 底下長時間 Telegram 顯示正在連接 的體感，重點不是蒐集最長的網域表，而是把 t.me 與 Telegram 官網／API 相關主機名，以及 MTProto 連線在規則表中的實際命中順序，和你選用的傳輸模式（系統代理或 TUN） 三者對齊。把這件事與 Discord 的即時語音 UDP 或 純文書 IDE 的長連線 分開理解，能少走冤枉路；完成後再針對節點地區做微調，就會有穩定得多的行動通訊體驗。若你尚未安裝合適的用戶端，歡迎先至本站用戶端下載頁取得對應平台版本，再依序套用本文步驟。→ 立即免費下載 Clash，開啟流暢上網新體驗