為什麼 TG 常卡在「連線中」：多網域、QUIC／UDP 與半代理

Telegram 客戶端在登入、同步聯絡人與媒體預覽時，會向多個主機名發起重試：除了大家熟悉的 telegram.org 與短鏈 t.me，實際連線還常包含API 端點、CDN 類靜態資源、以及依網路條件切換的傳輸方式。當你只看到「連線中」而沒有明確錯誤碼，常見原因並非「節點完全沒通」，而是一部分請求直連、一部分走代理，或 TCP 與 QUIC（UDP）走了不同決策路徑。排障第一步請對齊規則自上而下命中順序：若一條過寬的 GEOIP 或過早的 MATCH 搶先，你在後段為 telegram.org 寫的細則可能永遠不會被評估；請對照 規則分流最佳實踐 與 規則順序與 GEOIP／MATCH 修正，先回答「當前這包連線實際命中哪一條」，再談是否更換節點。

另一典型現象是網頁版正常、桌面程式卡住，或反過來：瀏覽器只吃系統代理堆疊，而原生程式可能直接使用自有堆疊或嘗試 QUIC。若你的 Clash 設定只顧及瀏覽器可見的 443/TCP，卻讓 UDP 落到錯誤策略或被防火牆／出口丟棄，介面就會長時間停在握手狀態。此時建議把 連線日誌與 TLS／逾時排查 與策略組行為交叉閱讀，並用圖殼匯出當下含 telegram、t.me 字樣的主機名，避免憑關鍵字猜測。

ℹ 先對齊觀測面：在連線中卡住重現當下匯出日誌，將 HTTPS 目標與同一時間窗出現的 UDP 目的地並排對照；若僅能看到 TCP 命中代理而 UDP 仍直連，優先懷疑 QUIC 與 TUN 覆蓋範圍。切勿把社群流傳的靜態清單當成永久真值——後端與邊緣會調整，仍以你自己的日誌為準。

分桶：telegram.org、t.me 與 CDN／附件觀測

實務上建議先依行為意圖分桶（實際子域與 CDN 會變；下列為方向說明，請用你的連線紀錄核實後再寫入規則）：

分桶後在 proxy-groups 建立單一意圖的策略組（例如 TG_APP）通常比散落多組易除錯；若長連線與大檔下載對節點要求差異大，再拆 TG_MEDIA。若遠端規則集更新 URL 本身常被誤分流，請一併檢查訂閱更新路徑，必要時參考 訂閱與節點維護指南。

QUIC、UDP 與 TUN：為什麼只開系統代理仍像斷線

QUIC 跑在 UDP 上；部分用戶端的行為是：若 QUIC 被阻或走錯出口，會再退回 TCP，但在某些網路下退回路徑極慢，畫面便長時間顯示連線中。若你僅啟用系統 HTTP／HTTPS 代理而沒有讓應用程式流量完整進入 Clash 決策，桌面程式仍可能自行發 UDP 試探。此時請閱讀 TUN 模式深度解析，理解透明代理如何把未走代理堆疊的程式流量一併納入。遊戲與連線類場景中 UDP 與規則集的實務也可參考 Steam UDP 與 TUN 規則集——核心精神相同：先確認 UDP 有沒有被你自己規則送去不想要的路徑。

節點池若對 UDP 支援參差不齊，可把 Telegram 綁到已驗證可用的策略組，或透過 url-test／fallback 找較穩定成員；但請記得：測速 URL 不代表 QUIC 友善，仍以實際連線日誌與地區政策為準。

桌面版、tdata 目錄與「只代理一半」徵兆

Windows／macOS 桌面版客戶端會在本機使用者目錄維護工作階段資料，常見目錄名為 tdata（名稱可能隨版本與封裝略有差異）。若你更換代理方式或規則後「第一次能登入、之後又卡住」，有時與快取的工作階段與新路由不一致有關：可優先在同一機器上比對完全退出程式 → 重啟與清快取／重登（會話與合規前提下）的差異，而不是直接歸咎節點。若桌面版仍與網頁行為背離，請回到 TUN 覆蓋與系統代理殘留兩條線索，並用 客戶端選型 挑一款便於匯出連線紀錄、切換模式的圖殼，降低手工猜測成本。

單列規則：放在 GEOIP／MATCH 之前的可維護寫法

所謂單列分流，指的是在 rules: 清單前段用一小段高置信度、經日誌驗證的 DOMAIN／DOMAIN-SUFFIX，把 Telegram 相關意圖整批指向同一策略組，再用後面的 GEOIP、規則集與 MATCH 處理一般流量。這樣做的好處是：當服務方新增子域時，你只需要補一行或更新規則集片段，而不是重新檢視整份訂閱。請避免「複製整套 AI／串流規則再手動刪除」——站內如 ChatGPT 網域分流 等文章與本文主機名不重疊，混用只會讓命中順序難以推理。

設定示意：TG_APP 策略組與網域片段

下列片段僅示範結構與命名；代理／直連、是否開啟 sniffing、以及是否允許 UDP relay，請依你的核心版本與合規邊界調整。寫入前務必以自己的連線日誌核對主機名；程式註解使用英文。

rules fragment (illustrative — verify hostnames in your logs) 
# Pin Telegram-related hostnames BEFORE broad GEOIP / rule-providers / MATCH
DOMAIN-SUFFIX,telegram.org,TG_APP
DOMAIN-SUFFIX,t.me,TG_APP
# Add CDN / API hosts observed in your logs into the SAME intent once verified:
# DOMAIN-SUFFIX,cdn-example-from-logs.invalid,TG_APP
# Avoid DOMAIN-KEYWORD unless necessary — it can cause false positives.
# If QUIC (UDP) must follow the same node policy, ensure TUN / udp routing is consistent.
# ... GEOIP, rule-providers, MATCH ...

註解中的 cdn-example-from-logs.invalid 僅為占位示例，請替換成你日誌裡真實出現的主機名。若補齊網域後仍見握手停滯，請用 Meta DNS、fallback 與 fake-ip-filter 對齊解析鏈，並搭配 Fake-IP 與區網／路由器 排除「規則顯示命中但實際連到另一組 IP」的假陽性。

驗證：日誌、DNS 與連線紀錄對齊

建議固定一份簡短驗證流程：重現 連線中 時匯出日誌 → 依時間戳對齊 TCP 與 UDP → 檢查策略名是否一致 → 暫時切換 TUN 開／關對照桌面程式行為 → 再回頭核對 DNS 與 fake-ip。若懷疑規則檔過舊，先確認本機 GEOIP／mmdb 是否拖錯大類（例如誤把海外邊緣當直連），可交叉閱讀站內資料更新類文章，但核心仍是日誌中的主機名字串而不是猜地區。

⚠ 合規提示：請遵守當地法規、Telegram 服務條款與雇主／校園網路政策。本文僅在你有權使用的出口與裝置上協助對齊路由與除錯，不鼓勵未經授權繞過存取控管或將網路資源用於違法用途。

自檢清單

在合法合規前提下，可依序檢查下列項目，多數「一直連線中」可收斂到可驗證原因。

  1. 重現問題時匯出紀錄，列出含 telegram、t.me 的主機名與並發的 UDP 連線，確認是否同一策略意圖。
  2. 檢查規則最前面是否有過寬條目搶命中；必要時依 規則分流最佳實踐 重排段落。
  3. 分別測試網頁與桌面程式；若僅一端異常，優先對照 TUN 與系統代理覆蓋。
  4. 對齊 DNS、DoH 與 fake-ip，排除解析與連線決策不一致。
  5. 若仍有 TLS 或逾時，沿 連線日誌與 TLS 排查 拆層。
  6. 關閉代理後若無法上網，依 關閉 Clash 後恢復上網 清理殘留，避免下一次量測失真。

結語

Telegram 的「連線中」往往不是單點故障，而是多主機名、CDN、TCP 與 QUIC／UDP、以及網頁與原生程式代理路徑疊加後的體感。把經日誌驗證的 telegram.org、t.me 與觀測到的資源網域收斂到同一 Clash 策略意圖，并把規則放在寬規則與 MATCH 之前，維護成本會顯著低於到處複製靜態清單。搭配 TUN、DNS 與連線紀錄，你可以用可重複的方法確認問題是在「規則沒命中」還是「命中了但節點對 UDP 不友善」。

與 Discord、Slack 等文章並讀，有助理解即時通訊產品的共通排障思路，但切勿混用主機名表；把 Clash 當成可觀測的決策層，才能在合規範圍內穩定還原你的使用體驗。

→ 立即免費下載 Clash，開啟流暢上網新體驗，用清楚的單列網域規則、UDP／QUIC 與 TUN 對照，把 Telegram 從無止境的「連線中」拉回可用狀態，而不是只靠重裝客戶端碰運氣。