1. MTProto と「ドメインだけ」では足りない理由
MTProto はメッセージ層の設計を指す語として広く使われますが、実務のトラブルシュートでは「どのホスト名で TLS を張っているか」と「実際のセッションがどの IP/ポートへ伸びているか」がセットで問題になります。ブラウザで web.telegram.org が開けても、デスクトップ公式クライアントが別のソケットで DC に直結していると、HTTP プロキシだけでは観測できない差分が残ります。
したがってClash 分流では、代表的なサフィックスを策略に載せることに加え、ルールが評価されるまでにトラフィックがコアに届いているかを確認する必要があります。ここで登場するのがTUN モードです。仮想インタフェース越しにスタックへ介入すると、プロキシ設定を読まないプロセスでも同一の rules: に乗せやすくなります。概要は TUN モードの解説を参照してください。
なお本稿は利用規約と所在国の法令を順守した通常利用を前提とし、回避目的の操作は扱いません。社内ネットワークでは管理者方針が最優先です。
2. 症状の地図:ログイン・同期・メディア・通話
接続タイムアウトが出る位置で分岐を付けます。起動直後の認証や更新取得で止まるなら、インストーラ/更新系ホストや証明書検証、DNS の汚染が疑われます。会話一覧は出るがメディアだけ回るなら、CDN や別ホストへのレンジ取得がルール外に落ちている典型です。テキストは流れるが通話だけ不安定なら、TCP よりUDPや特定ポートの扱い、あるいは回線側の UDP 劣化を疑う段階です。
購読テンプレートの更新自体が不安定な場合は、Clash の購読更新と TLS・DNS の稿で手前のレイヤを先に潰すと、Telegram 単体の切り分けがしやすくなります。
ルールの共通の考え方は ルールルーティングと サブスクリプションの取り込みにあります。以下では Telegram 特有の束ね方に絞ります。
3. システムプロキシと TUN:どちらで DC まで届くか
OS のシステムプロキシは、HTTP/HTTPS を尊重するアプリには効きやすい一方、ネイティブクライアントが独自スタックで外向きに開くケースでは取りこぼします。Telegram 公式アプリは環境によってSOCKS5 やプロキシ設定を別 UI で持つこともありますが、Clash 側で一つのルール表に揃えたいなら、TUN で一度コアに集約し、DOMAIN-SUFFIX などで出口を決める運用が再現性が高いです。
Windows では UWP やループバック例外が絡みます。TUN と UWP・ループバックの稿と併読してください。macOS ではネットワーク拡張の許可や GUI の既定トグルが絡むため、macOS の Verge Rev 初回設定の判断枠をそのまま当てはめられます。
TUN をオンにしてもすべてが自動的に海外出口へ出るわけではなく、最終的には MATCH 行と広い GEOIP の順序が支配します。国内向けトラフィックを誤って迂回しないよう、具体的なサフィックスを上に、粗いルールを下に置く基本を守ってください。
4. ルールに載せたいドメインの出発点
インフラ側のホスト名は変更され得るため、手元のコアログやクライアントの接続表示に出た名前を正としてください。出発点として多くの環境で登場しやすい例として、telegram.org(公式サイトや一部取得)、t.me/telegram.me(共有リンク)、core.telegram.org(開発者向けドキュメントや API 周辺の参照)、desktop.telegram.orgや配布に関わるホスト、web.telegram.org(Web クライアント)などが挙げられます。
メディア取得はCDN やリージョン別のホストに分かれやすく、telegram.org だけを載せてもサムネイルや動画だけタイムアウトが残ることがあります。ログに繰り返し現れる未登録名を DOMAIN-SUFFIX で足し込む運用が現実的です。DC への接続はドメインではなく IP とポートとしてログに出ることも多く、その場合はスニッファや DNS の設定でドメイン評価に乗せられるかを先に確認します。
音声系の UDP 取り扱いの考え方は、ボイス中心の Discord 向けの稿と対比すると理解しやすいです。Netflix や Disney+ のような長尺ストリーミングの地域表示とは検索意図が異なり、本稿では Telegram の同期・DC・通話に焦点を当てます。
5. mihomo ルール例:TELEGRAM 策略の上に DOMAIN を置く
実務では Telegram 用の策略グループを一つ切り、遅延の少ないノードを選べるようにしておくと運用が楽です。自動選択は便利ですが、セッション中に出口が頻繁に変わると再接続が増えるため、常用するなら比較的固定の選択にも寄せてください。
以下は構造の例です。プロキシ名と順序は環境に合わせて置き換え、広い MATCH より上に具体的な行を置きます。
# proxy-groups: optional dedicated group for Telegram stack proxy-groups: - name: TELEGRAM type: select proxies: - NODE-A - NODE-B - DIRECT # rules: place Telegram suffixes above broad GEOIP / MATCH rules: - DOMAIN-SUFFIX,t.me,TELEGRAM - DOMAIN-SUFFIX,telegram.me,TELEGRAM - DOMAIN-SUFFIX,telegram.org,TELEGRAM - DOMAIN-SUFFIX,core.telegram.org,TELEGRAM - DOMAIN-SUFFIX,desktop.telegram.org,TELEGRAM - DOMAIN-SUFFIX,web.telegram.org,TELEGRAM # Add DOMAIN-SUFFIX lines from core logs for media/CDN hosts seen in your region. - MATCH,PROXY
実際の購読では RULE-SET に寄せることも多いですが、追記行が末尾に沈んで評価されないことのないよう、テンプレートのブロック構造を毎回確認してください。
6. UDP と通話:Discord 稿との違い
Telegram の通話や一部リアルタイム機能は、クライアントや回線条件に応じてUDP を使うことがあります。Clash 系では TUN と tproxy まわりの設定、およびノード側が UDP を中継できるかがボトルネックになり得ます。Discord のボイスと同様、HTTP プロキシだけでは UDP を取りこぼすという整理は共通です。
一方で Telegram はMTProto と DC 構成が前面に出やすく、症状も「通話だけ」に限らず同期やメディア取得に現れます。UDP が原因かどうかは、同じノードでテキストのみと通話を短時間比較し、ログでプロトコル表示を追うと切り分けやすいです。キャンパス Wi‑Fi やキャリアのUDP レート制限では、ルールを完璧にしても改善に限界がある点も念頭に置いてください。
7. DNS・fake-ip・スニッファで名前と経路を一致させる
fake-ip構成では、クライアントが握る IP とルール評価時のホスト情報にズレが出やすく、DOMAIN-SUFFIX を増やしても策略に乗らないことがあります。スニッファ(sniffer)で TLS の SNI 等から実名を復元し、再評価に回すのが定石です。キー名はバージョン差があるため、手元の mihomo ドキュメントを正としてください。
ブラウザが DNS over HTTPS を独自に使う場合、OS のリゾルバと Clash の DNS セクションが別物として動くことがあります。Web と公式アプリで挙動が違うときは、その差分も疑ってください。HTTPS の誤マッチの追い方は Sniffer と SNI の稿が参考になります。
8. 実測チェックリスト
次の順で進めると抜け漏れが減ります。(1)TUN をオフにし、システムプロキシのみで Telegram を起動し、ベースライン(接続状態・同期速度)を記録する。(2)TUN をオンにし同条件で比較する。(3)コアの debug ログで、代表ドメインが意図した策略名にマッチしているかを確認する。(4)未登録ホストがあればルールへ追加し、ピーク時間帯と深夜の二点で再測定する。
自動選択系の挙動を詰める場合は url-test/fallback の稿も参照してください。企業端末ではポリシーが技術的解より優先されるため、管理者への確認が必要なケースもあります。
9. つまずきと法令・利用規約
第一に、telegram.org だけを追加して終わりにすることです。メディアや DC 向けトラフィックが別ホストのまま残ると、一覧は出るが添付が回る、という状態が消えません。
第二に、TUN を有効にしても特定プロセスだけ迂回するケースです。他社 VPN、企業デバイス管理、例外アプリのリストが典型です。
第三に、Telegram の利用規約とローカル法令を順守してください。本稿は正当な範囲での経路整理に限定します。
10. まとめ
Telegramの不調は、MTProto と複数 DC・ドメイン、メディア取得経路、必要に応じたUDPが重なって起きます。Clash/mihomoでは、TUN で経路を集約しつつドメイン分流を整え、DNS・fake-ip・スニッファで名前と策略を一致させる——この三層が、2026 年現在も「接続タイムアウト」「更新失敗」「メディアだけ止まる」といった検索ニーズに対して再現性のある骨格になります。
ホスト名は変わり得るため、最終的には自分のログに出た名前を正としてルールを足し込む運用がいちばん確実です。GUI とコアの世代で既定値が異なるため、安定したクライアントから環境を揃えたい場合は、 → 無料で Clash をダウンロードし、快適な接続体験を試す ところから始めるのがおすすめです。
関連記事 · 同じテーマ
トピックの近さで選んだ関連記事 — 同じカテゴリの Clash 実践ガイド。
Clash の購読(サブスク)更新が失敗する?Windows でログから TLS・DNS を切り分ける(2026)
ブラウザでは購読 URL が開けるのに mihomo だけタイムアウト・証明書エラーになるとき。ログで DNS・TLS・HTTP を分類し、システムプロキシと mixed-port の自己参照、購読元の 403/UA まで順に潰す。Verge Rev 稿・LAN 共有稿と補完。
続きを読むFigma が開かない・ずっと読み込み?FigJam 含むメイン域と静的 CDN を Clash(mihomo)で分流する実測(2026)
白画面・スピナー・キャンバスだけ出ないとき、figma.com 系と static.figma.com 等を FIGMA 策略へ束ね、DNS・fake-ip・Sniffer で名前と経路を一致。埋め込み・デスクトップ差分は TUN とログで切り分け。Notion/Reddit 稿と同型、開発者向け AI 稿と棲み分け。
続きを読むReddit が開かない・読み込みが遅い?メインと CDN を Clash で分流し DNS・Fake-IP を校準(2026)
reddit.com・redd.it・redditstatic 等を専用策略へ束ね、サムネ・プレビュー・静的 JS の別名をログで拾い足す。DNS・fake-ip・Sniffer で名前と経路を一致。Discord/Steam 稿と同型だがドメイン集合は Reddit 向け。Netflix/YouTube 長尺稿と棲み…
続きを読む