📖 チュートリアル ⏱ 約19分で読めます

Telegram が繋がらない／画像が回り続ける？Clash のドメイン分流と直結例外を段階実測（2026）

Clash を有効にしたまま、Telegram のデスクトップ版やスマートフォン版だけが「接続できない」「接続タイムアウトを繰り返す」「文字は届くのにメディア読み込みのスピナーが止まらない」といった症状に悩まされることは、実運用でかなり多いパターンです。原因は単一ではなく、プロキシに載せるべき DOMAINと意図的に 直結（DIRECT）に残すべき帯の食い違い、DNS とルール解決のズレ、ノード品質、あるいはクライアントが MTProto 系の経路をどう取るか、が重なります。本稿は、ネット上の固定リストに頼りすぎず、接続ログを正にしながら 分流ルールと 直結例外を育てる手順を、コピーして調整できる例つきで整理します。音声・UDP 寄りの切り分けは Discord 向けの実測記事 とはアプリの通信特性を分けた、Telegram 特化のガイドです。

先に切り分け：Clash を外すと一気に直るか

作業の出発点は一貫して、「Clash を事実上バイパスしたときだけ、Telegram の症状が消えるか」を見ることです。クライアントのプロキシ設定をオフにする、Rule ベースの運用をやめて短時間 Direct 相当に寄せる、あるいは TUN／システムプロキシの取り込み方を切り替えて挙動を比較する、といった形で十分です。ここで明確に良くなるなら、端末の故障より先に、出口の取り違え・DNS・ルール順序のどれかを疑うのが合理的です。逆に Clash とは独立して症状が出るなら、回線、ISP 側の制限、Telegram 側の一時的な不調、端末の省電力設定など、もう一段広い要因を見る段階に移ります。

ルール型プロキシの価値は、そこに留まりません。どのドメインがどの出口に流れたかを追えることにあります。だから本題では、感覚論ではなく、Rule ヒット行と宛先のメモに基づいて足し算・引き算をしていきます。基礎の型は proxy-groups と カスタムルール入門で押さえ、ここでは Telegram 周りのドメイン束ねと、直結例外的な扱いに焦点を絞ります。

Telegram の通信が Clash で噛み合いにくい理由

Telegram は、表向きの telegram.org 系の Web 周りに加え、クライアントの実接続や大容量の画像・動画では、CDN 系や MTProto に近い振る舞いの経路に分散しやすいアプリです。その結果、同じ「テキストは届くのに、添付のサムネイルが回る」現象でも、手元では 別ホストに対する TLS／TCP の束が生じており、分流ルール上は「会話用だけ PROXY へ、メディア用は想定外の MATCH 以降」といった分断が起き得ます。さらに、地域・ISP・モバイル回線の組み合わせによっては、特定の帯域だけ直結の方が速い、という逆説も珍しくありません。ここで重要なのは、日本語ブログに転がる汎用リストをそのまま信じるのではなく、自環境のログに出た文字列を DOMAIN-SUFFIX や DOMAIN-KEYWORD に反映していく姿勢です。

また、接続タイムアウトの背景には、ノード落ち、ハンドシェイク失敗、DNS が返した宛先と実接続の乖離、fake-ip とルール行の no-resolve の組み合わせ、など多層の要因が重なります。一度に三か所以上を同時に弄ると原因が分断されるため、DNS だけ／ルールだけ／モードだけの順に一つずつ変えて再現性を測るのが安全です。HTTPS の見え方が妙な場合は、sniffing と DNS の整理も併読すると迷いが減ります。

「プロキシに載せる」と「直結に残す」がぶつかる典型

利用シーンの代表例を挙げます。A さんの環境では、会話用の *.telegram.org 系を PROXY_TELEGRAM に向けた一方で、国内キャッシュや特定 CDN 名が GEOIP,CN 系の直前に誤爆して、メディア取得だけ別出口に落ち、結果として 画像の読み込みが伸びる。B さんの環境では、逆に MATCH が広すぎて、ローカルや同一 ISP 内の方が速い帯まで遠方ノードに流れ、遅延に見える。C さんの環境では、モバイル回線の IPv6 周りと Clash の取り込み方が衝突し、デスクトップ版だけ不調、という二系統。いずれも、単一の「正しい DOMAIN 一覧」では説明しきれないため、直結例外の置き所は自宅回線の実測に合わせて調整するのが通例です。

例外として、職域や学域の透過型プロキシ、大学 VPN、社内ゼロトラストと併用している場合、オーバーレイの経路が二重化し、Telegram だけ挙動が悪化することがあります。このときは、まずオーバーレイの一方を外してベースラインを取るのが先です。トンネル全般の雰囲気を押さえたい場合は、Clash と VPN の違いの整理も助けになります。

ルール例：DOMAIN で束ね、必要なら DIRECT 例外を上に置く

以下は YAML の骨格例です。PROXY_TG は、ご自身の proxy-groups 名に置き換えてください。実運用では、ログに出た表記を追加し、順序を実測に合わせて入れ替えます。上から評価される前提で、直結にしたい行を先に置く、という当たり前が効きます。

# Example only — adjust PROXY_TG to your proxy-groups; extend domains from logs
rules:
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DOMAIN-SUFFIX,t.me,PROXY_TG
  - DOMAIN-SUFFIX,tdesktop.com,PROXY_TG
  - DOMAIN-SUFFIX,telegram.org,PROXY_TG
  - DOMAIN-SUFFIX,telegra.ph,PROXY_TG
  - DOMAIN-SUFFIX,telesco.pe,PROXY_TG
  - DOMAIN-SUFFIX,cdn.telegram.org,PROXY_TG
  - DOMAIN,telegram-cdn.com,PROXY_TG
  - DOMAIN-SUFFIX,telegram-cdn.com,PROXY_TG
  - GEOIP,CN,DIRECT
  - MATCH,PROXY_TG

この例の最後の MATCH を DIRECT に寄せる運用と、PROXY に寄せる運用では、国内サイトまで遠回りになるリスクの取り方が真逆です。自宅回線の方針に合わせて選んでください。GEOIP,CN,DIRECT の行位置は、購読テンプレと矛盾しないよう、既存の全体ルールのなかで整合を取るのが重要です。メディア専用の DOMAIN だけ一時的に DIRECT に切り替え、改善するなら、ノード品質以前に経路取り違いの疑いが濃厚です。

メディア読み込み：CDN 名と拡張子よりログを正に

画像・動画・大きなドキュメントは、クライアントのバージョン・地域・帯域状況で別名のホストに落ちることがあります。だから、ネット上の古い DOMAIN 一覧に縛られず、スピナーが止まらない瞬間のRule ログの宛先をスクリーンショットやメモに残す習慣が効きます。多くの場合、cdn 系・dc 系の文字列を含むホスト名が一緒に現れ、そこに REJECT 手前の挙動や、意図しない PROXY グループへの落下が起きます。行き先が安定しているときは、同一ノードに固定しつつ、ドメイン束ねだけを少しずつ拡張します。

一方で、同じ「画像が回る」でも、実際には DNS が返した IPv4/IPv6 のどちらにコネクションが張られているかで見え方が変わるケースもあります。端末の VPN、別系統の DoH、OS の暗号化 DNS が同時に有効だと、解決は成功したのに、実体の接続は別というズレを起こしがちです。取り扱いは、まず Clash 内蔵 DNS の一本化に寄せ、それでも残る部分だけ OS 設定を切る、の順が扱いやすいです。より下位の取り込み幅を広げる必要がある場合は、TUN モードも選択肢の一つですが、併用ソフトが増えるほど衝突の調査工数は増えます。

DNS／fake-ip／no-resolve：ルールと名前解決の三つ巴

「ルールに DOMAIN を足したのに、期待どおりの行に乗らない」背景には、解決前ルールと解決後ルールの違い、fake-ip の戻し先、no-resolve の有無、といった DNS 周りの設計とセットで起きるズレが入り混じります。典型的には、手元のルール上は telegram.org にマッチするはずが、クライアント実装が別の CNAME やエッジ名で張り直し、IP ベースの後段に滑り込む。あるいは逆に、名前だけ見て PROXY へ向けたが、実体の SNI や接続名が別で、嗅探まわりの挙動と干渉する。ここは一発逆転の呪文より、小さな変更の積み重ねで収束させる方が再現性が高いです。

加えて、接続タイムアウトのログが出るのが DNS 前か後かを見分けるのが実務的です。前なら、リゾルバの到達性・ブロック状況・DoH フォールバック。後なら、ノードの遅延、TLS 失敗、宛先都合。どちらに転んでも、一発で REJECT に着いていないか、広すぎる RULE-SET に飲み込まれていないか、をログの行番号と突き合わせます。ルール型エディタの使い方はクライアントごとに差がありますが、「どの行に、どのプロセス／どのドメインが乗ったか」を読めるかどうかが分水嶺です。

デスクトップとモバイル：取り込み方の違いに注意

Windows や macOS の Telegram デスクトップは、OS のシステムプロキシに従うとは限りません。一方、Android／iOS クライアントは、VPN 的な取り込みや、端末内の専用トンネル実装、メーカー省電力の都合で、同じ DOMAIN でも別経路に流れることがあります。

  • PC：システムプロキシだけでは取り切れない場合、TUN に寄せ、ログに Telegram プロセス名相当の行が出るかを比較します。
  • スマートフォン：端末専用の Clash 系クライアントの実装差が大きく、Per-App 的な扱いや、バックグラウンド制限の影響を疑います。

遠隔会議系の帯域と混ざって見える場合、同じ「メディア重い」でも仕組みは違います。例として Zoom／Teams 向けの会議帯 の切り分け手順の骨格は流用できますが、UDP 優位の帯は Discord 向けの方が近いです。本稿の主眼は、会議でも音声でもなく、Telegram のメッセージ・添付の安定化に置いています。

おすすめの実測手順（メモ用チェックリスト）

  1. 他プロキシを止める。ブラウザ拡張、別系統 VPN、社内端末向けエージェントのオーバーレイを外し、Clash 単体に近づけます。
  2. ベースラインを取る。短時間 DIRECT 相当に寄せ、同じ操作で メディアが開くか確認します。
  3. 取り込み方を比較する。システムプロキシと TUN、必要ならポート系の扱いを切り替え、ログに会話用・添付用の行が出るかを比べます。
  4. ドメイン束ねを拡張する。スピナー中の 宛先文字列を DOMAIN／DOMAIN-SUFFIX に反映し、同一ノードに固定して再現性を測ります。
  5. 直結例外の試行。候補の DOMAIN だけ一時的に DIRECT にし、改善幅とプライバシーのバランスを決めます。
  6. DNS だけ変える週末。同じ手順をもう一巡し、名前解決が支配因かを切り分けます。

切り分け表は、将来の自分や家族が読んでも辿れるように、日付とクライアント版、回線名を添えておくと、再診断が格段に楽になります。

よくある質問

ルールを真似たのに、まだ画像が回る

同名でも地域エッジが違う、CNAME 連鎖で別名に出ている、より手前の広いルールに飲まれた、などが考えられます。ログ上の宛先を増やし、順序の前後を見直してください。

テキストは届くのに、動画とスタンプが不安定

メディア専用ホストの束が足りていない、または帯域のノード遅延が支配的、が典型です。同一ノードに固定のうえ、メディア系 DOMAIN をログから追加し、一時的な DIRECT 試行で経路要因を切り分けてください。

接続タイムアウトが特定時間帯だけ増える

ノード側の混雑、回線夜間の帯域制御、Telegram 側のエッジ切り替えが重なることがあります。時間帯をまたいでノード名を替え、DNS のフォールバックも含め、ログの出方が変わるか比較してください。

まとめ

Telegram が Clash 利用中だけ不調なとき、まずは 分流ルールの穴と 直結例外の置きすぎ／不足を、ログと DNS の両輪で詰めていくのが近道です。固定リストを盲信するより、手元の行に出た DOMAIN を正に、会話帯と メディア読み込み帯を分け、必要なところだけ一時的に DIRECT を上に置く判断が、現場では繰り返し効きます。

クライアント導入は、配布面の一貫性のため 本サイトのダウンロードページを第一候補にすると、記事の手順との突き合わせがしやすいです。初歩操作は チュートリアルで押さえ、本稿の例を土台に、ご自身のログへドメインを足してみてください。ルールの可視性と切り替えの柔らかさは、Clash 系の強みであり、接続タイムアウトの切り分けでもそのまま力を発揮します。他ツールより「どのホストが、どの出口に流れたか」を追いやすい点は、Telegram のような多ホスト展開のサービスほど価値が出ます。改善の手応えを確かめたい方は、→ Clash を無料でダウンロードし、Telegram 向けのドメイン分流を試す から始めてください。ソースやライセンスの参照は、利用規約の理解のために、公式のオープンソース情報へのアクセスを別枠で行う形がおすすめです。