Telegramが接続中のまま？Clashのドメイン分流とMTProto切り分け

1. 「接続中」のまま止まるときに疑う順序

Clash をオンにした状態でだけ症状が出るなら、(1) クライアントがシステムプロキシ経由で捕まっているか／TUN で全ソケットを拾えているか、(2)rules: が t.me や telegram.org 系より手前で 広い GEOIP／GEOSITE に吸われていないか、(3)Mihomo 系ログで当該接続が どの Host／SNI と policy になっているか、(4)DNS が国内向け名前解決だけ返していないか、の順が扱いやすいです。ブラウザ版 Telegram Web は Electron 版とは FQDN 集合が異なるので、問題がネイティブアプリのみならログはそのデスクトッププロセス側に合わせてください。

ヒント：「アプリ側で SOCKS5 を直接指定」の設定をオンにすると、OS のプロキシとは別経路になるケースがあります。Clash と二重になるとログと実体がずれるので、アプリ側の「接続タイプ」を一度シンプルな状態へ戻し、システム代理か TUN 一元化で再現確認すると切り分けが速いです。

2. Telegram が触るドメインの「層」

公式クライアントは地域・バージョンで変動しますが、分流を設計するときの土台としては次のような名前の束を意識すると追いやすいです。

サイト・ダウンロード・開発者領域：telegram.org、core.telegram.org。
短リンク・ログイン関連：t.me、telesco.pe／telegram.me など（表示名だけでなくログ上の別名にも注意）。
データセンター系ホスト（IP 直下は IP-CIDR）：通信ログにtelegram と番号／地域が付いたホスト、や amazonaws.com／CDN 配下がある場合があります。名前がブロックリストにだけ載っていて本体がDIRECTに落ちると、一覧同期だけ未完、という分かれ方が出ます。
音声・通話・大きな並列 TCP／UDP：通話まわりは MTProto の「デフォのメッセージチャネル」とは別の UDP／ICE 系が絡むことがあり、ボイス重視の記事のようにプロセスと UDPを疑う段階が別に存在します。

いずれもルール先勝ちの上で、DOMAIN-KEYWORD,telegram 一括より、ログに出た 実 FQDN を DOMAIN-SUFFIX で足していく方が誤爆が少ないです。

3. MTProto が使うポートと「Desktop」クライアントの前提

MTProto はメッセージング用プロトコルで、実装とクライアント設定により443/TCPを主に使い、混雑時やブロック回避の文脈で5222/TCP 等の代替が使われる説明が一般的です。ここを「特定の TCP 番号さえ開けば必ず通る」と決めつけず、実際のダイアログ接続ログで :443 かどうかを確認してください。UDP の全面ブロックはボイス・通話に効きますが、テキスト同期だけ止まる主因はしばしば名前解決とルールのすれ違いです。

Windows／macOS の公式デスクトップ版は、システムの「インターネットにプロキシを使う」設定を見るか、独自のSOCKS5／HTTP プロキシを埋め込むかの違いがあります。Clash Verge 系の「システムプロキシ」だけでは拾えないソケットがある場合はTUN モード（当サイトの TUN・Windows 切り分け）で OS 全体をトンネルに載せると差が出ることがあります。

注意：ブロック回避目的の「独自 MTProxy」や第三者プロキシをアプリ側にだけ指定すると、あなたの Clash YAML のルールと完全に別物になります。この記事での整理はすべての外向き TCP／UDP が一つのコアに集まる構成が前提です。

4. Clash（Mihomo 系）の分流ルール例

以下は学習用の最小構成です。購読 RULE-SET と併せる際は、このブロックより上に置く／専用 RULE-SET を足すなど、自分の並びに合わせてください。

# Example only — match real FQDNs from logs
proxy-groups:
  - name: TG
    type: select
    proxies: [YOUR_STABLE_PROXY, DIRECT]

rules:
  - DOMAIN-SUFFIX,t.me,TG
  - DOMAIN-SUFFIX,telegram.org,TG
  - DOMAIN-SUFFIX,telegram.me,TG
  - DOMAIN-SUFFIX,telesco.pe,TG
  # Add IP-CIDR DC ranges from YOUR logs after verification
  - MATCH,...

GEOIP より前に Telegram 向け規則を置き忘れると、その出口がブラウザ用 PROXY とアプリ用 DIRECT に分かれ、同期だけ遅延する症状が出ます。ドキュメントの rules の優先度と、TLS ハンドシェイク切り分けも併せて参照してください。

5. DNS と Fake-IP：名前とルールの一致

Fake-IP を使う場合、ブラウザの DoH と Clash 内蔵 DNS が二重だと、表示名とコア内部のマッチングが食い違い、「一部のホストだけタイムアウト」に見えます。fake-ip トラブル記事の手順で fake-ip-filter に telegram 周辺を入れるか、一時的に fake-ip を切って比較すると切り分けが早いです。

6. 策略グループとノード：揺れを抑える

url-test ばかりに任せると、短い周期で出口が入れ替わり、セッションの再ハンドシェイクに見える「断続」が出ることがあります。Telegram を触っている間だけ TG 策略を手動 select で固定し、落ち着いたら戻す、という運用が取りやすいです。パラメータ調整は url-test 記事に譲ります。

画面の様子	よくある原因	先に試すこと
アイコンだけ固まる	静的配信ドメインが別 policy	ログの FQDN を `TG` に追加
メッセージだけ遅い	MTProto の TCP が `DIRECT`	規則の順・TUN の有無を確認
通話だけ不可	UDP／ICE がトンネル外	TUN と UDP とファイアウォール
ログに TLS 失敗だけ	ノード側 SNI／証明書問題	別ノードで比較、TLS 記事へ

7. Discord／Steam の「プロセス＋ UDP」記事との違い

当ブログにある Steam／Discord 向けの Windows 事例は、「特定の .exe と UDP」を Clash で拾う論点が前面です。Telegram デスクトップはメインのチャット同期がMTProto／TCP を中心とした名前付きホストへの接続列として現れやすく、入口はドメインベース分流とログ上の複数ホストの束ねが中央に来ます（通話を常用する環境では UDP 論点も重なり得ます）。目的が違うので、対症のノブもポート開放一覧より規則と DNS とモード（TUN）側が先です。

8. セルフチェック

症状再現直前からログを保存し、telegram 関連ホストがどの policy に乗ったかを一覧化する。
t.me／telegram.org／ログに現れた CDN 系をすべて同じ策略に入れたか確認する。
TUN をオフ／オンで挙動差を比べ、システムプロキミスを疑う。
Fake-IP／DoH を切り、アプリのみを対象にもう一度試す。
ノードは一時固定してから、url-test 併用の影響を見る。

9. まとめ

Telegram のデスクトップ版が接続のまま終わらないとき、単一サービスとはいえ名前と経路が層になり、Clash の分流ルール順とDNS と実行モードが噛み合わないケースが多いです。MTProto を意識しつつ、ログで開いているポートと Host を確認し、telegram 系ホストを一つの策略グループにまとめる。音声や通話で UDP が絡んだら別途 TUN／UDP の軸へ進む、この順で大抵は症状の「居場所」が絞れます。細かく接続ログを読めるオープンな Clash／Mihomo 系は、クローズドソフトウェアのみのセットアップより切り分けに向いており、そのメリットを日常のチャット環境にも活かせます。

→ こちらから Clash を無料ダウンロードし、Telegram 用にドメイン分流を試してください