Telegram Desktop 停在「連線中」？以 Clash TUN、進程分流與 telegram 網域逐步修復
許多使用者在安裝或啟用 Clash（含 Clash Meta／Mihomo 系核心與常見圖形客戶端）後，Telegram Desktop 會長時間顯示連線中、頭像與媒體載入不完整，或出現僅能收發文字、語音與視訊異常、多裝置訊息不同步等「半套連上」的體感。這類問題很少只靠換一個城市節點就消失：它往往牽涉是否走 TUN、規則順序、telegram.org 與相關 API／DC 主機名是否命中正確策略組，以及 MtProto 常用的 TCP／UDP 是否被泛用規則誤導或遭中間設備干擾。本篇以可操作的順序，說明如何搭配 PROCESS-NAME、PROCESS-PATH 與網域規則，對齊桌面端實際連線行為，並與站內 Discord 語音與 UDP／TUN 專文場景互補。
先辨識「連線中」背後是哪一種失敗
Telegram 客戶端對外觀常把多條後台通道包在同一個狀態列裡；因此「連線中」可能同時包含：帳號授權與金鑰交換（偏 HTTPS 與 API）、與資料中心（DC）之間的 MtProto 長連線，以及語音通話等額外路徑。當其中一條被錯誤分流、DNS 回傳不可路由位址，或 UDP 在節點／本機防火牆被丟棄時，介面有時仍顯示「好像有連上」，但貼圖、大檔與語音就會卡在不同階段。
- 文字勉強通、媒體全掛：常見於 API／CDN 子域未完整走代理，或
fake-ip與實際出口不一致。 - 永遠轉圈、聯絡人列表空白：多與
api.telegram.org、core.telegram.org等控制面請求被擋或走錯出口有關。 - 聊天室進得去、語音一按就斷：請優先懷疑 UDP 與節點對 UDP 的支援度，並對照下文與 Discord 語音文的排查順序。
實務心法
先開連線日誌，記下行程名稱、目的主機名或 IP、傳輸層協定與命中規則，再動設定；每回合只改一個變因，否則很難判斷是 DNS、規則還是節點行為。
為什麼常建議開 TUN，而不只靠系統代理
Windows 與 macOS 上的「系統代理」對 Electron／Chromium 類應用通常友善，但 Telegram Desktop 的網路堆疊並不保證永遠尊重系統代理；在部分環境下，仍會嘗試直連或走與瀏覽器不同的解析路徑。當本機已安裝 Clash 並開啟 TUN（虛擬網卡／核心轉發）時，流量較容易在統一攔截點進入規則引擎，您才能穩定使用 PROCESS-NAME、PROCESS-PATH 與域名規則組出的策略鏈。
若您尚未完成 Windows 端基線，建議先依 Clash for Windows 安裝與 TUN 教學確認驅動、模式與訂閱可連；macOS 使用者請先完成 Clash Verge Rev macOS 設定，再回來微調 Telegram 相關規則。記得日常請維持在 Rule 模式，避免長期以 Global 掩蓋規則設計錯誤，否則除錯訊號會被雜訊淹沒。
MtProto、DC 與「telegram 網域階梯」
Telegram 桌面端與伺服器之間的主流協定為 MtProto，並會與多個資料中心（DC）協調工作階段。您不必背下所有 DC 編號，但要理解：客戶端除了連到使用者看得見的 telegram.org 官網與說明文件外，還會連到多組API、靜態資源、WebApp、CDN子域；其中一部分走常見 HTTPS 埠，另一部分可能是長連線或不同埠位。若您的訂閱規則習慣「境外整包丟給代理、其餘直連」，而 Telegram 的關鍵主機名落在直連卻被 ISP 干擾的區間，就會出現連線中或同步延遲。
下列主機名僅作工程示意，實際清單會隨版本與後端調度變動；仍以您客戶端日誌為準，並避免過度寬鬆的 MATCH 蓋掉細緻規則。
| 類型（示意） | 常見主機片段 | 備註 |
|---|---|---|
| 官網／說明 | telegram.org |
與客戶端控制流量未必同一批，但可作 DNS 與規則是否生效的參考 |
| HTTP API | api.telegram.org |
登入、同步、機器人等常見入口 |
| 靜態／更新 | core.telegram.org 等 |
資源與更新檢查；被廣告攔截表誤傷時會像「半套連上」 |
| Web／K 線介面 | web.telegram.org、plato 相關子域 |
偏瀏覽器場景；桌面內嵌 WebView 時行為可能不同 |
| 短連結與公開頁 | t.me |
分享連結解析；與主連線通道分開看待 |
撰寫 DOMAIN-SUFFIX 時，請注意規則合併順序：遠端規則集若含有過舊或過激的 Telegram 相關列，可能與您本機補丁互相打架。建議在圖形介面中暫時關閉可疑規則集交叉驗證，再分段加回。
以 PROCESS-NAME／PROCESS-PATH 鎖定 Telegram Desktop
在 Clash Meta／Mihomo 系核心中，進程類規則能把「這條連線是誰發起的」講清楚，特別適合 Telegram 這種單一主程式＋多協定的客戶端。相較於只靠域名，進程規則能減少「同一主機名被多個應用共用」時的誤判。
- Windows：常見執行檔為
Telegram.exe；若使用可攜版或多開目錄，可改用PROCESS-PATH指到完整路徑。 - macOS：應用程式包內二進位名稱請以活動監視器與日誌為準，必要時用路徑規則避免同名程式衝突。
- Linux：套件版與 AppImage 的檔名可能不同，請勿直接抄論壇範例而不核對。
進程規則務必放在過寬的 GEOIP 或最終 MATCH 之前，否則永遠輪不到它生效。若您同時使用桌面版與瀏覽器版 Telegram，兩者的行程名稱不同，請分別觀察日誌，不要混用同一組規則。
# Illustrative rules — replace PROXY with your policy group; verify process names on your OS
rules:
- PROCESS-NAME,Telegram.exe,PROXY
# - PROCESS-PATH,C:\Apps\Telegram\Telegram.exe,PROXY
- DOMAIN-SUFFIX,telegram.org,PROXY
- DOMAIN-SUFFIX,t.me,PROXY
- DOMAIN-SUFFIX,telegra.ph,PROXY
- DOMAIN-SUFFIX,telesco.pe,PROXY
- MATCH,DIRECT
別忽略「只代理文字」的節點特性
部分商業節點對 UDP 支援不完整，或對特定埠位限速；此時 TCP 文字仍可能勉強可用，語音與即時通話卻失敗。請在相同策略組下測試 UDP，必要時更換節點或供應商，而不是無限堆域名規則。
UDP、語音與 DPI／中間盒場景
語音通話與部分即時功能仰賴UDP 或混合路徑；若您曾讀過站內 Discord 語音與 UDP／TUN 一文，可以把類似思路遷移過來：先確認 TUN 是否攔截到該行程的 UDP，再確認節點與本機防火牆是否丟棄。某些網路環境會對長連線或特定指紋進行DPI 或流量整形，外觀像「時好時壞的連線中」；此時可嘗試更換傳輸方式（依您節點供應商支援為準）、分段測試直連與代理、並避免在同一台機器上疊加多個互相搶路由的虛擬網卡。
若懷疑是 DNS 與 fake-ip 造成的「半套連線」，請交叉閱讀 DNS 與 fake-ip 排查，先讓解析與路由一致，再回頭微調 Telegram 專用規則。
DNS、Sniffer 與日誌欄位
TUN 模式下，DNS 請求與後續 TCP／UDP 連線的對齊方式會影響規則命中。若開啟了 Sniffer 或類似功能，請確認與您的隱私與相容性需求相符，並留意排除清單是否誤傷 Telegram 相關 TLS。閱讀日誌時建議固定看四件事：行程、SNI／主機名、協定、策略組名稱；比對您 YAML 中的順序，很快就能定位是「規則沒寫到」還是「寫到了但被更前面的規則吃掉」。
建議排查順序（濃縮版）
- 確認 Clash 在
Rule模式、TUN 正常啟用且無多餘舊版虛擬介面殘留。 - 重現問題時擷取 Telegram 相關連線，記下主機名與 TCP／UDP。
- 為
Telegram.exe（或實際行程）加上明確策略組，並放在寬鬆規則之前。 - 補齊日誌中出現的 API／CDN 子域，避免只靠過時靜態表。
- 分別測試文字、圖片、語音；若僅 UDP 失敗，優先換節點與檢查防火牆。
常見誤區：不是多塞幾條域名就會好
實務上最常見的錯誤，是把論壇上抄來的「超大 Telegram 域名表」直接貼進規則最前面，卻沒有檢查與訂閱內建規則的優先順序。結果可能是：舊表把已下線的主機名寫進去，反而讓核心延遲在無謂的重試上；或某條 DOMAIN-KEYWORD 過寬，把不相關流量也塞進同一策略組，拖慢整體握手。較穩的做法仍是「日誌驅動」：只為您機器上實際出現、且確實影響連線的主機名補規則，並在變更後保留一段可對照的連線紀錄。
另一個誤區是假設「只要 Telegram 走代理，其他應用不受影響」。當 TUN 啟用且規則鏈很長時，每個連線都要走完比對；過長的鏈條與過多的遠端規則集合併，會放大 CPU 與延遲。建議定期清理不再使用的規則集，並把與 Telegram 強相關的進程規則維持在小而精的前段。若您使用多個 VPN 或過濾軟體，也要確認是否只有一個虛擬網卡在管理預設路由，避免「看似開著 Clash，實際部分封包繞過」的分裂行為。
最後，桌面版與手機版帳號若長期不同步，除了網路路由，也要排除客戶端版本過舊、工作階段衝突、或公司裝置管理（MDM）限制後台連線等非 Clash 因素。網路層排查與應用層排查應並行，才不會把應用程式錯誤誤判成節點問題。
合規與責任使用
本文僅討論在您有權管理的裝置上，如何以 Clash 類工具做網路診斷與路由最佳化。請遵守當地法律、網路使用政策與服務條款；若所處網路環境對特定服務有限制，請以合法合規方式處理。
小結
Telegram Desktop 在 Clash 環境下的「連線中」往往不是單點故障，而是 TUN 是否真正攔截到客戶端流量、進程與域名規則是否在同一條邏輯鏈上，以及 TCP 與 UDP 是否在節點與 DNS 兩端都一致 的綜合結果。先用日誌把主機名與行程對齊，再用 PROCESS-NAME／PROCESS-PATH 與 telegram.org 系網域逐步收斂，通常比盲目更換節點城市更有效。