一、先對齊現象：「正在連接」多半是幾條路沒對齊

Telegram 用戶端要同時完成多件事：與資料中心建立工作階段、同步對話列表與草稿、載入頭像與媒體預覽、檢查更新與安全補丁。當你看到畫面長時間顯示正在連接，瓶頸可能落在「與核心 API 的握手與長連線」尚未成功，也可能落在「某一條 CDN 或更新網域仍被直連規則截走」導致重試迴圈。此時若只盲目更換節點，往往無法對症下藥，因為問題可能根本不在頻寬，而在規則命中或DNS 解析鏈。

因此，請避免一開始就把所有症狀都歸因到單一策略群組。較務實的做法是：先在 Clash 連線清單中觀察，當你點開 App、切換對話或重新登入時，實際出現哪些主機名稱、各自命中哪一條規則、是否出現預期之外的 DIRECT。若你尚未成功匯入訂閱或策略名稱不確定，建議先完成《Clash 訂閱連結怎麼用？機場設定檔案一鍵匯入完整教程》，避免在錯誤的群組名稱上反覆試錯。

二、為什麼要分開談 MTProto、CDN 與 WebSocket

在社群語境中，MTProto常泛指 Telegram 用來與伺服器通訊的協定家族；實務排查時，你不必先背協定細節，但要理解「哪些連線決定你能不能登入與收發訊息」，以及「哪些連線只影響圖片載入或更新下載」。前者多半對應到 api.telegram.org、core.telegram.org 這類與帳號工作階段高度相關的主機名稱；後者則可能落在 CDN、靜態物件或版本檢查相關路徑上，兩者的延遲敏感度和失敗表現並不相同。

CDN 分流類流量通常以 TCP 為主，目標是把物件盡快送到裝置；若這類請求被規則拆到與 API 不一致的出口，常見體感是「文字偶爾能出現、圖片永遠轉圈」或「列表出得來、頭像永遠灰階」。至於 Telegram Web 或部分內嵌瀏覽元件，則可能依賴 WebSocket 長連線；這類連線若被中間設備或過寬的關鍵字規則誤傷，也會表現成頁面空白或長時間載入。把它們拆開思考，才能對應到正確的Clash 分流規則順序與 DNS 設定。

三、為什麼「只開系統代理」常常仍卡在正在連接

許多桌面環境預設只對「遵循系統 HTTP 代理」的程式生效；Telegram 用戶端可能以自有網路堆疊發起連線，或與瀏覽器走不同的解析與快取路徑。即使你已在作業系統中開啟代理，仍可能遇到部分連線未進入 Clash 核心，導致規則與日誌對不起來。實務上，若症狀主要發生在Telegram Desktop而非網頁版，我們通常會優先建議你驗證 TUN 模式是否能讓相關程序一致進核心，因為它能在網路層統一接管符合條件的流量。

啟用 TUN 會涉及路由與系統權限，請先閱讀《Clash TUN 模式開啟方法》再操作，並在開啟後回到連線清單確認是否出現與 Telegram 相關的程序或目標主機。若你同時使用 WSL2 或 Docker Desktop，也可對照《WSL2 共用本機 Clash 代理》理解「哪些流量預設不會自動跟著 Windows 代理走」，避免把問題誤判成單一聊天軟體故障。

四、建議排查順序（先證明流量有進核心，再談節點）

下列順序刻意把「換節點」放在中後段：先確認 Telegram 相關連線有經過 Clash，且規則命中符合預期，再談線路品質。

  1. 確認 Clash 正在執行，並依場景選擇系統代理或TUN；若問題主要出在桌面或手機 App，優先驗證 TUN 或裝置層是否完整接管。
  2. 在觸發「重新連線」或「切換帳號」時，於連線日誌中檢查是否出現 telegram.org、api.telegram.org、t.me 等常見後綴，以及策略是否為預期的代理群組，而非被過寬的 DIRECT 規則提前截走。
  3. 載入貼圖、預覽圖與大型媒體時，再次檢視日誌：是否出現與 CDN 或靜態物件相關的主機名稱，並確認它們沒有與登入流量拆到互相矛盾的出口。
  4. 檢查 DNS 模式（是否 fake-ip）、以及 Telegram 相關後綴是否在 fake-ip-filter 或 nameserver-policy 中有合理設定，避免解析與連線策略互相打架。
  5. 在規則已正確命中的前提下，再挑選穩定、掉包低的節點；若仍長時間顯示正在連接，才需要回到 MTProto 連線是否被上游網路干擾、或資料中心路由是否異常等層面。

若出現埠號占用、訂閱無法拉取等通用錯誤，請併讀《Clash 常見報錯解決方案》；本文聚焦 Telegram 場景下的Telegram 代理路徑與連線失敗對齊。

五、網域怎麼收集：以日誌為準，不要只抄懶人包

Telegram 會依版本、區域與資料中心調整連線目標；第三方整理的清單可作起點，但最可靠的方式仍是在你自己的環境收集主機名稱。於用戶端內觸發同步、開啟媒體與檢查更新時，在 Clash 連線清單中依關鍵字篩選 telegram 或 t.me，把重複出現的後綴整理成 DOMAIN-SUFFIX。

將觀察到的名稱依後綴分組後，優先使用 DOMAIN-SUFFIX 對齊整棵子網域樹，比過寬的 DOMAIN-KEYWORD 更不易誤傷其他服務。若你看到圖片或更新檔來自第三方公有雲邊緣，請只加入「該次失敗時間點實際命中」的後綴，避免把整個超大後綴一刀切進代理，拖慢其他網站。

六、實務上常見的主機名稱方向（以實測為準）

下列方向為多數環境下登入、同步與官網流程會出現的典型後綴家族；實際是否全部需要、以及是否應走同一策略群組，請以你的連線日誌為準：

  • telegram.org：官網、文件與部分下載／版本資訊相關請求。
  • api.telegram.org：與 Bot API、部分 HTTP 介面相關（桌面與手機用戶端亦可能出現類似 API 路徑）。
  • core.telegram.org：文件與開發者資源常見；若你同時開發 Bot，日誌中可能更常出現。
  • t.me：公開頻道連結、使用者名稱解析與短流程相關請求。
  • desktop.telegram.org：桌面版安裝與更新檢查相關（實際前綴可能隨版本變化）。
  • 網頁版相關環境可能出現 web.telegram.org 及帶有 web.telegram.org 子域的 WebSocket 主機名稱；請以日誌為準個別補規則。

重點在於：能開啟程式但永遠連不上線時，優先懷疑與工作階段／資料中心相關的 API 類主機名稱是否誤直連；能收文字但媒體全掛時，優先核對 CDN 類子網域是否與登入流量同一出口。

七、DNS 與 fake-ip：別讓解析鏈放大「正在連接」的感受

在 fake-ip 模式下，Clash 會先回傳虛擬位址再在連線階段決策出口。若 DNS 與規則配合不當，可能出現「解析看起來成功、實際 TLS 對錯出口」或反覆重試。Telegram 用戶端在連線階段會持續嘗試多個路徑，任一條解析被汙染或指向不理想的路徑，畫面就可能長時間停在正在連接。

實務上可以分兩步：第一，確認你的 DNS 上游對相關網域可信且可達；第二，對反覆出問題的後綴在用戶端支援的欄位中設定較穩定的解析策略（例如指定 DoH），並在調整後用連線日誌比對命中是否與預期一致。若改 DNS 後同步明顯恢復，代表瓶頸有相當比例在解析鏈路，而非單純節點速度。

八、分流設計檢查清單（請以你的日誌為準）

下表整理撰寫 Telegram 代理相關規則時的檢查角度；欄位中的後綴會隨營運調整，務必以實測主機名稱為準。

類型常見主機名稱方向設定提示
登入與同步api.telegram.org、telegram.org 等與 MTProto／API 工作階段同一策略脈絡，避免一半走代理、一半直連。
CDN 與媒體日誌中出現的靜態或邊緣主機名稱與文字同步拆開優化時，注意兩條出口仍須各自可達，不要只顧其一。
短連結與公開頁t.me若邀請連結或預覽異常，確認未被前置攔截規則誤傷。
桌面更新desktop.telegram.org 等更新檢查失敗時，獨立觀察該時間點日誌，避免與聊天同步混淆。
網頁版 WebSocketweb.telegram.org 等長連線與一般 HTTPS 請求不同步排查；必要時關閉過度關鍵字規則測試。

九、分流規則範例（請替換為你的策略群組名稱）

下列 YAML 片段示範「把 Telegram 相關後綴明確指向代理群組」的寫法；請將 PROXY 替換為實際策略群組名稱，並維持規則順序：更具體的 Telegram 條目應放在過寬的 MATCH 與地區直連清單之前。若你希望「核心 API」與「CDN／更新」分流到不同群組，可定義 PROXY_CORE 與 PROXY_CDN，再依日誌微調。

# Example only — replace PROXY_CORE / PROXY_CDN with your policy group names
rules:
  - DOMAIN-SUFFIX,telegram.org,PROXY_CORE
  - DOMAIN-SUFFIX,api.telegram.org,PROXY_CORE
  - DOMAIN-SUFFIX,core.telegram.org,PROXY_CORE
  - DOMAIN-SUFFIX,t.me,PROXY_CORE
  - DOMAIN-SUFFIX,desktop.telegram.org,PROXY_CDN
  - DOMAIN-SUFFIX,web.telegram.org,PROXY_CORE

若日誌中出現其他專用主機名稱，請以 DOMAIN-SUFFIX 逐條補上；不確定時寧可先記錄完整主機名稱，再查後綴歸屬，避免關鍵字規則過寬。

十、手機版與桌面版：症狀類似但連線型態可能不同

手機在切換行動網路與 Wi‑Fi 時，DNS 與 MTU 變化較大，可能放大「看似同一套規則、卻只有某一種網路會卡住」的體感。建議你在兩種網路下各收集一次連線日誌，比對是否有額外的更新檢查或推送相關主機名稱被直連規則截走。若你希望系統化了解 Android 用戶端匯入與分流設定，可參考《Android 手機安裝 Clash 完整教程》作為基礎設定入口，再回到本文補 Telegram 專用規則。

桌面版若同時開啟網頁版分頁，請注意兩者可能重複建立長連線，除錯時建議先關閉瀏覽器分頁、只保留單一用戶端，避免日誌混雜。

十一、圖形用戶端中如何少踩坑

在 Clash Verge Rev 等用戶端中，建議開啟即時連線清單，篩選 telegram 或上述後綴關鍵字，逐條確認策略。若某條顯示 DIRECT，請回到規則表檢查是否有廣告攔截、地理分流或「繞過區域網」類規則前置命中。

若桌面端基礎設定尚未完成，可先依《Clash Verge Rev 完整設定教學》跑通訂閱與模式，再回到本文補 Telegram 專用規則，可節省大量試錯時間。

十二、小結：把「正在連接」變成可驗證的規則問題

2026 年在桌面或手機上遇到 Telegram Desktop與官方用戶端長時間顯示正在連接時，可依序確認：用戶端流量是否進核心、DNS 與 fake-ip 是否一致、MTProto／API 與 CDN 是否各自命中，以及網頁版 WebSocket 是否被誤傷。當連線日誌能清楚對應主機名稱與策略，你就不需盲目更換節點卻無法改善體驗。

當你希望把觀測、規則與核心更新集中在同一套成熟用戶端時，官方維護方案通常能降低手寫 YAML 的低階錯誤；相較其他同類工具，Clash 在規則透明度與日誌對照上往往更一致。→ 立即免費下載 Clash，開啟流暢上網新體驗