1. 症状の読み解き：「接続中」は単一障害ではない

Telegram の UI が「接続中」のまま止まるとき、裏側では認証状態の確認、DC へのセッション確立、チャット一覧と差分同期、メディアのプレビュー取得が並列に走っています。どれか一つがタイムアウトしてリトライを繰り返すと、ユーザーにはただのスピナーに見えます。Clash の接続一覧に出るホスト名と実際に選ばれた策略を時系列で並べると、「API 相当はプロキシで通っているのに、添付取得だけ DIRECT で詰まっている」といった部分的成功が想像以上に早く見えてきます。まずは一枚岩のドメイン想定でルールを書かない前提を共有します。

YAML の骨格やルールモードをまだ把握していない場合は、先にサブスクリプション取り込みの記事で設定ファイルの流れを押さえておくと、以降の手順が読みやすくなります。

2. MTProto・CDN・Web／WebSocket を「層」に分ける

以下は設計メモとしての区分であり、実際のサブドメインは環境で変わります。Telegram は独自プロトコル（MTProto）を中心にしつつ、周辺で HTTPS や CDN、ブラウザ連携を併用します。

層イメージ切り分けのポイント
コア接続（MTProto）データセンターへの長寿命セッションログインは通るのに同期だけ遅いとき、DC まわりの経路と UDP／TCP の扱いを疑う。
Web・公開ページtelegram.org、t.me、web.telegram.org 系ブラウザでは開けるのにアプリだけ止まるとき、クライアント固有のホストをログで確認。
CDN・静的取得添付、スタンプ、プレビュー画像などテキストは即時でもメディアだけ遅いときに、CDN サフィックスが別策略に落ちていないかを見る。
WebSocket／補助チャネル通知や一部クライアント実装の補助接続プロキシの WebSocket 透過性やタイムアウト、中間機器の影響を疑う。

2026 年時点でもクライアントは頻繁に更新されるため、過去に動いていたルールが突然効かなくなることは珍しくありません。購読ルールに頼り切らず、自分のログで一度表を作り直すのが安全です。

3. Telegram Desktop とモバイルの違い（プロキシの見え方）

Telegram Desktop（Windows／macOS／Linux）は、OS のシステムプロキシ設定を参照する典型です。一方、Android／iOS の公式アプリは、VPN プロファイルやアプリ内設定、ベンダー実装の差で経路の見え方が変わります。モバイル側の一般的な切り分けはAndroid に Clash Meta を入れる手順も参照しつつ、本稿では主にデスクトップのログ収集と分流にフォーカスします。いずれのプラットフォームでも接続ビューに出るホスト名を正にしてください。

4. ドメイン収集：ログイン直後とメディア表示を分けてログを取る

収集の基本は次の流れです。「接続中」再現と「添付だけ遅い」再現は別シナリオとして切り出すと読みやすくなります。

  1. Clash を起動し、システムプロキシまたは TUN を有効化する。併用中の別 VPN は一旦切る。
  2. Telegram を起動し、「接続中」が長引く状態を再現する。接続ビューで同時刻付近のホストをメモする。
  3. 別セッションで、画像の多いチャットを開きメディアの読み込みを促す。CDN 系のホストが増えるタイミングを記録する。
  4. DIRECT や想定外のポリシーに落ちている行に印をつけ、購読ルールのどの行より上に自作ルールを置くべきかを検討する。

ポート占有やコア起動失敗など汎用トラブルはトラブルシュート記事へ。本稿は Telegram 特有のマルチドメイン構成に焦点を当てます。

5. 推奨する切り分け順序

  1. Clash が起動していること、システムプロキシかTUNのどちらでトラフィックを握っているかを確認する。
  2. 接続ログで Telegram 関連ホストが意図したポリシーグループに入っているか、誤った DIRECT がないかを見る。
  3. fake-ip を含む DNS 設定を確認し、必要なら特定サフィックスへ nameserver-policy 等を当てて名前解決のブレを減らす。
  4. Web・MTProto 周辺・CDN をホスト／サフィックス単位でルール化し、購読ルール内の広い DIRECT より上側に矛盾なく配置する。
  5. テキスト同期とメディア取得を別々に検証し、必要なら別ポリシーグループへ振り分ける。

6. システムプロキシと TUN：取りこぼしを減らす

システムプロキシは手軽ですが、プロキシ設定を読まないコンポーネントや、別ドライバの VPN と併用すると見かけ上の経路が分裂します。TUN はルーティング層で取り込むため一貫性は上がりますが、他 VPN との競合や権限まわりのトレードオフがあります。有効化するならTUN モードの解説を参照し、有効化後に再接続ログで Telegram 関連ホストがすべて期待どおりの経路になったか検証してください。Windows で UWP や Store 系アプリと併用する場合はUWP のループバックと Clash の記事も参考になります。

7. DNS／fake-ip：名前解決とルール判定のズレ

fake-ip は体感速度を上げる一方、設定次第では「ルールに渡る前の名前」と「実接続の宛先」の整合が崩れやすくなります。Telegram のようにサブドメインと CDN が多いサービスでは、軽いズレでもクライアントがリトライを繰り返し、ユーザーにはただの「接続中」や送受信の遅延に見えます。対策の基本は、上流 DNS を信頼できるものにそろえ、ログで頻出する主要サフィックスへ専用の名前解決ポリシーを当てることです。フィールド名はコアのバージョンで差があるため、利用中の Mihomo／Clash Meta のドキュメントと照合してください。

8. 分流ルールの考え方（記述例は置き換え前提）

購読ルールに「広い DIRECT」が先に入っていると、意図せず国内直結へ落ちるホストが紛れ込みます。より具体的な DOMAIN／DOMAIN-SUFFIX を、矛盾なく上側に置くのが実務的です。以下は例示であり、実際のホスト名は必ずログで確認して置き換えてください。telegram-cdn や地域別 CDN のサフィックスを丸ごとプロキシに載せると、他サービスへ副作用が出る場合があります。ログに出た特定サブドメインに絞るか、ルールセットの細分化を検討してください。

# Example only — verify hostnames in your Clash logs before use
rules:
  - DOMAIN-SUFFIX,telegram.org,PROXY
  - DOMAIN-SUFFIX,t.me,PROXY
  - DOMAIN-SUFFIX,telegra.ph,PROXY
  - DOMAIN-SUFFIX,telesco.pe,PROXY

MTProto の実宛先が IP 直指定になるケースでは、ドメインルールだけでは足りず、ログに出た IP レンジや GEOIP ルールの検討が必要になることもあります。その場合は誤ルーティングのリスクが高まるため、最小限の範囲に留め、必ず接続ログと突き合わせてください。グループ名は proxy-groups に定義済みである必要があります。

9. Discord／Steam 向け記事との違い

当サイトの Discord 記事は、更新取得とボイス RTC のマルチドメインが中心です。Steam 記事はストアと CDN ダウンロードが中心です。本稿は Telegram の MTProto コアと Web／CDN の周辺にスコープを絞り、メッセンジャー特有の長寿命セッションとメディア取得の両方を扱います。用途が違うアプリを併用する方は、それぞれ別のホスト表を持つと混乱が減ります。Discord 向けの手順はDiscord の CDN／RTC 分流記事を参照してください。

10. ノード選定：帯域より「揺れの少なさ」とプロトコル相性

スピードテストで一位でも、短時間で往復遅延が跳ねるノードは、メッセンジャーの同期や再送には不向きです。TLS の再ハンドシェイクが増え、クライアント側はタイムアウトや「接続中」として現れます。手動選択で様子を見たり、Telegram 専用に安定路線を固定するのが実用的です。UDP を扱う経路では、ノード側の制限やキャリアグレード NAT の影響も出やすいため、別ノードを試す前に経路の一貫性を先に確認する方が再現性が高いです。プロトコル特性の比較はプロトコル比較記事も参考になります。

11. 追加の落とし穴：複数 VPN、IPv6、企業プロキシ

Clash 以外の常駐 VPN と TUN を同時に有効にしている場合、ルートの奪い合いで「ときどきだけ直結」が紛れ込みます。IPv6 が有効な回線では、IPv4 側だけプロキシに乗っているといったデュアルスタックの偏りも起きます。企業ネットワークでは HTTPS インスペクションが MTProto や長時間接続を阻害することがあるため、その場合はネットワーク管理者の方針に従う必要があります。別 PC へプロキシを配る場合は、LAN プロキシの記事で allow-lan とファイアウォールの要点を押さえてください。

12. まとめ：証拠ベースで MTProto と CDN を束ねる

Telegram が「接続中」のまま進まない症状や、メッセージとメディアで速度が極端に違うケースは、単一設定ミスよりもモード・DNS・ルール順・ノードの揺れの積み重ねで起きがちです。本稿の順序どおりにログで確認していけば、「とりあえず別ノード」より再現性の高い改善が期待できます。2026 年もメッセンジャー基盤は変化が早いので、購読ルールに頼り切らず、自分の環境で一度ホスト表を更新する習慣を持つと安心です。

接続ログとルール編集を GUI でまとめられるクライアントを使うと、YAML を毎回手で触る負担も下がります。同種ツールのなかでも、策略表示とコアの整合が取りやすい製品ほど長く運用しやすい印象です。Telegram を安定して使いたい方は、→ Clash を無料ダウンロードして、快適な接続体験を始める