📖 教學 2026 年 4 月 24 日 ⏱ 約 20 分鐘閱讀

Telegram 連不上或圖片一直轉圈？Clash 網域分流與直連例外分步實測

許多人明明已開著 Clash（含 Clash Meta／Mihomo 系譜客戶端），Telegram 桌面版或手機上仍出現連線逾時、訊息延遲、圖片與貼圖一直轉圈、或語音與小影片載不出來。和本站Discord 語音與 UDP／RTC 分流專文不同：Telegram 多數主通道走 MTProto 常見的 TCP 連線，痛點更常落在網域沒寫全、規則被訂閱內寬條目提前帶去錯的出站、或媒體 CDN 與 API 沒有對齊同一策略。本篇從你搜尋時真正會打的關鍵字出發：先學會判斷「該走代理的網域」與「可嘗試直連例外」的情境，再用 DOMAIN／DOMAIN-SUFFIX 寫可維護的 分流規則，最後以連線日誌與 DNS 做一次可重複的分步實測，把媒體載入與主連線的分岔症狀分開看，避免只在客戶端亂切節點卻沒有命中根因。

先把症狀分桶：是「整個斷線」還是只有「圖與檔案」轉圈？

在調任何 DOMAIN 規則之前，建議先把體感切成三類。第一類是應用程式顯示連線中斷、長時間顯示連線中或無法同步聯絡人，這比較接近控制面與 API沒有穩定抵達伺服器，通常與 api.telegram.org、core.telegram.org 或客戶端實際使用的主機有關。第二類是文字能即時到、群組列表正常，但圖片、影片、貼圖、語音永遠在轉，這多數落在媒體下載與 CDN 子網域，可能與主通道被不同條規則接走有關，也可能與你所在地對特定 CDN 的路由品質有關。第三類是關掉 Clash 就恢復、但開啟就異常，這幾乎一定表示流量經過核心之後的出站或 DNS 路徑與直連不同，要回到「規則＋節點＋直連測」而不是怪 Telegram 本體壞掉。

行動裝置上還要額外想到：廠商省電、背景限制、分身的網路權限，都會讓你誤以為是Clash 規則有問題。若只有特定網路（例如家裡光世代正常、4G 異常）才復現，也要先排業者與 IPv6 行為，再進入 分流規則微調。本文主軸仍放在可寫進設定檔的 網域層面，與讀者最常搜到的關鍵字：Telegram、Clash、分流規則、直連例外、媒體載入、連線逾時。

與「語音專用」類文章差在哪？為什麼不能照抄 UDP 專文？

本站 Discord 語音斷續一文強調 UDP 與 WebRTC 的即時性；Telegram 雖然在部分情境也會牽涉不同傳輸層，但多數使用者在 Clash 日誌裡先看到的仍是大量 tcp 連到 149.154.0.0/16 之類的資料中心段，或各種 *.cdn.telegram.org、telegra.ph 週邊。也就是說：你要優先寫好以網域與行為分流的規則骨架，必要時再考慮更細的埠或協定條件，而不是一開始就套用寬到不行的 KEYWORD 或盲目開全域名。

另一個常見誤解是：「我把 telegram.org 代理了，就等於全好了。」實務上，媒體載入常落在另一棵主機樹、或 被 GEOIP 提早送去直連。若你所在地直連該 CDN 其實更快，錯誤的代理出口反而會讓圖與大型檔案顯得「永遠轉圈」。因此本篇會同時處理該走代理與可嘗試直連兩條敘事，讓你依日誌證據選邊，而不是只背一份永不更新的網域表。

第一步：確認 Telegram 的流量「有沒有進到 Clash 核心」

在 Windows 或 macOS 上，只開啟「系統 Proxy」有時不會讓所有行程完整走核心；Telegram Desktop 往往仍能運作，但實際拆開會發現少數連線沒有依你想像的方式被攔截。實務上多數人會用 TUN 模式或等效能力，讓應用程式層的連線盡量納入同一套策略；觀念可對照Clash TUN 模式深度解析，先把誰被接管界定清楚。驗證方式很單純：開啟客戶端連線日誌或即時清單，在應用程式內觸發一次圖片載入、貼圖、以及重新連線，觀察是否出現帶有 telegram 字樣或已知資料中心字首的主機名稱。若你完全沒有看到相關條目，先別急著堆 DOMAIN，而是要回到模式與權限，否則後面寫的分流規則都不會被命中。

手機上若使用 VPN 類權限 或分應用程式分流套件，敘事相同：先確定 Telegram 行程的封包有進到同一個核心。若沒有，症狀會表現成「我明明照文章貼了 YAML 卻像沒用」的挫折感。若你希望部分 App 有獨立策略，可延伸閱讀自訂規則教學：讓指定 App 走指定節點，但請記得在支援的前提下再套程序規則，避免過度複雜而難以除錯。

第二步：釐清「應走代理」的典型網域層次（起手式，而非永久完整表）

以下列出教學用、常見的後綴與產品面主機，實務上 Telegram 會隨版本與地區改動後端。請以你當下日誌中實際出現的主機名稱為最終依據，本節的價值在於幫你建立分層思考：哪些像帳戶、更新、服務探測、哪些像內容與說明文件。一般情況下，若你所在網路不適合直連到 Telegram 後端，會希望至少下列後綴落在同一個可信任、能穩定連上國際網的代理群組內，並放在容易被誤傷的寬條目之前。

# Example starter — extend with your live connection log hostnames
rules:
  - DOMAIN-SUFFIX,telegram.org,TELE-OUT
  - DOMAIN-SUFFIX,t.me,TELE-OUT
  - DOMAIN-SUFFIX,tdesktop.com,TELE-OUT
  - DOMAIN-SUFFIX,telesco.pe,TELE-OUT
  - DOMAIN,api.telegram.org,TELE-OUT
  - DOMAIN,core.telegram.org,TELE-OUT
  - DOMAIN-SUFFIX,telegra.ph,TELE-OUT
  - MATCH,Main

說明：① 規則由上而下匹配，先命中者勝；訂閱內的 GEOIP,CN 或「繞過大陸」之類的條目若放在太前面，可能在你自訂的 Telegram 條目之前就把少數實際落點在特定區段的主機送錯，需要依你的檔案實況重排。② TELE-OUT 應替換成你實際存在的 proxy-group 名稱，也可直接指向一個專用 select 節點群組，細節可讀Clash 代理群組（proxy-groups）完全指南。③ 若你從 Web 版使用，還要補上瀏覽器實際命中的 web.telegram.org 等主機，否則只顧 api 仍可能缺一角。

第三步：媒體與大檔——何時要補 CDN、何時要懷疑「被代理反而慢」？

當 媒體載入遲滯、縮圖轉圈，而文字仍大致正常，請在日誌中尋找與 cdn、cdn4、檔案或貼圖相關的主機。這些流量往往量大、重試窗口長，體感上比文字聊天更容易「轉起來不見盡頭」。有兩條很務實的處理路徑：一是把你在日誌中看到的實際 CDN 後綴併入與 TELE-OUT 相同的群組，確保不會因為寬條目被丟到預設出口；二是在 A／B 測試中，針對可證實的少數子網域暫改為 DIRECT，觀察是否立刻改善。第二條不是「全網都該直連」的意識形態，而是實測導向：在部分地區，直連到特定 CDN 的 RTT 與丟包表現，確實可能優於一顆不適合大檔的遠端節點。

寫 直連例外 時，請盡量用具體的 DOMAIN 或窄後綴，並保留註解說明你哪天看到它出現在日誌，以免半年後自己忘記。過寬的 DOMAIN-KEYWORD,telegram 有時能「救急」，卻也增加誤傷與除錯難度，不是長期維護的首選。若你懷疑 Fake-IP 與實際 TLS 目標脫節，請把測試期間的 DNS 收斂到單一決策，再看規則命中與實際連線是否一致；Clash Meta 嗅探與分流例外在少數客戶端上也能幫你解讀「嗅探導致的主機看起來怪」的現象，避免誤把 DNS 層的落差當成節點當機。

分步實測建議清單：一次只改一個變因

要同時改規則、又換三顆節點、再切 DNS，最後很難知道到底是哪一個步驟救了你。建議用下列可重複順序，每一步只動一件事，並在相同網路環境、相同聊天室內用固定檔案（例如一張 2MB 的圖）做觀察。

驗證日誌可見性：開日誌，重開應用程式、開一個大型頻道，看是否有帶關鍵字的主機、協定欄位是否符合預期。
檢查命中哪一條規則：在同一時間窗內，確認最終出站群組，排除被訂閱內的寬 GEOIP 或 MATCH 提前帶走。
做代理 vs 直連的對照：僅針對已鎖定的一顆網域，暫改 TELE-OUT 成 DIRECT 或反過來，觀察媒體是否立即改善。若兩邊都差，偏向業者或上游節點，而非你單一條 DOMAIN 寫錯。
掃一輪 Clash 分流規則順序：把 Telegram 相關條目提到會誤傷的條文之前，再重測。必要時參考Clash 使用教學，把基礎模式與訂閱匯入先整理乾淨。
審查 DNS：特別是 fake-ip 與是否有多層本機 / 路由器 DNS 同時參一腳的狀況；症狀常像「有時候圖能刷、有時候永遠轉圈」。

仍卡在連線逾時？先釐清訂閱與節點，而不是再加一百條規則

有時你貼了看似完美的 DOMAIN 清單，仍遇到長時間沒有回應、或 TLS 層遲遲不完成。這可能是上游訂閱本身延遲、丟包、或出口在特定時間窗擁塞。若你把同一出口換成可信任的另一組仍無改善，就該同時讀懂訂閱連結常見問題，而不是只在應用程式裡反覆重開。也別忘了：代理只能改變路徑，沒有辦法讓一個在商業上遭限制的帳戶變成「可跨區全功能」；我們討論的是網路可達性與 媒體載入，不是幫人繞開服務條款。

與全隧道 VPN 的心智差異

若你曾習慣一鍵 VPN 全機隧道，突然改成規則分流，最常見的陣痛是「以為有開代理、其實只有部分行程吃到」。Clash 與 VPN 有什麼差別？一文整理了典型的取捨與觀測點。對 Telegram 這類多連線的 App，規則型架構的優點是能把控制面、媒體面、週邊拆開調整，缺點是你必須願意看日誌與願意維護 YAML。只要你接受「先證實、再寫死規則」的流程，體感通常會比盲目全域穩定。

合規與風險提醒

任何代理工具都會改變你的連線路徑，上游與中繼在技術上可能觀察到流量形態。請遵守你所在地與服務條款所允許的用法，並保護帳戶與裝置安全。本文僅就技術觀測與 Clash 分流規則的撰寫思路提供參考，不構成違法或違反他人條款的操作指引。若需要核對授權與專案資訊，可自行前往專案頁面；一般使用者取得與更新安裝檔，建議以本站下載頁為主，避免安裝來歷不明的套件。

常見問題

我已經把 telegram.org 全部代理了，圖還是轉圈，為什麼？

常見情況是實際承載圖與大檔的主機在另一棵子網域或 CDN 上，沒有被你寫的後綴覆蓋，或被更早的寬條文提前命中。請以轉圈當下的連線日誌為準，補上真實主機名稱，而不是再複製一條一樣的後綴。

什麼時候該用 DIRECT 當 直連例外？

當實測顯示代理出口對特定 媒體 CDN 的延遲與丟包明顯比直連差，而你在政策與法規上允許直連該目標，可以把該主機寫成窄條的 DIRECT。請保留日誌證據，並避免一次放行過大的後綴。

手機上症狀與電腦不一樣，是同一套規則嗎？

觀念相同，但攔截方式、省電與背景限制不同。手機上要先確認 Telegram 行程的封包確實進了同一顆核心，再談 DOMAIN 微調。若兩邊行為不同，常見是其中一邊沒有完整納入核心或兩邊 DNS 設定不一致。

把 Telegram 在 Clash 環境下調到「能長期用」的狀態，核心通常是：先讓日誌看得見真實主機，再依證據寫 分流規則，有需要時針對 媒體載入補上或收回 直連例外，並讓 DNS 與 fake-ip 的決策在測試期間只保留一套。這比關掉代理硬上、或永遠依賴全域模式，都更容易讓人理解自己網路裡的瓶頸。若你正在尋找能穩定承載 規則型代理與 TUN 流程的用戶端，不妨從本站取得合適的桌面或行動版本，實際感受命中規則是否夠直覺——→ 立即免費下載 Clash，開啟流暢上網新體驗。