「接続中」で止まるとき、まず疑う層

他の Web やアプリは通るのに、Telegram だけスプラッシュのまま、あるいは左上に接続中表示が抜けない——Clash Telegram 分流で検索に辿り着く多くのケースは、この「一見同じ不調」に見えて、実際は次のいずれかに分かれます。(1) 短縮 URL の t.metelegram.me への到達(WebView・ブラウザ連携含む)がルール上ミスマッチしている。(2) クライアント本体が使う MTProto ベースのセッションが、想定と違う出口やポートに乗っている。(3) 名前解決と実接続の宛先がズレて、ルールが意図せぬ MATCH に落ちている。

Discord のように UDP 音声が前面に出るアプリ(Discord 向け分流記事)とは検証の焦点が違います。Telegram はブラウザ版・デスクトップ・モバイルで接続手順が異なり、検索では「プロキシは有効なのにずっと接続中」といった言い回しで語られる症状でも、層を分けてログを取ると再現性が上がります。ここからは t.me、MTProto、ドメイン単位のルールを一つのストーリーとして整理します。

t.me / telegram.me が絡む理由

招待リンクや共有 URL は https://t.me/… 形式が一般的です。ブラウザで開くと telegram.org 系のページや、地域設定によっては別ホストにリダイレクトされることもあります。Clash 側は「どのドメインの TLS 接続をどの proxy-groups へ流すか」で挙動が決まるため、t.me だけ抜かれていると、画面は出ても深いところの API が別経路、という非対称が起きます。

少なくとも候補に上げるのは、t.metelegram.metelegram.orgweb.telegram.orgdesktop.telegram.orgcore.telegram.org など、公式が案内する更新・ドキュメント・Web クライアント周りのホスト名です。クライアントのメジャーアップデートでサブドメインが増えることもあるため、ドメイン分流のリストは「一度きりの聖典」ではなく、ログでヒット行を追う前提が安全です。購読している RULE-SET に Telegram 用が含まれていても、自前の DOMAIN-SUFFIX上寄りに置くと、どの行が勝ったかを追いやすくなります。

MTProto 規則:プロトコル層のイメージ

Telegram クライアントは独自の MTProto プロトコルで、主に 443/TCP(環境や設定で変化し得る)上にセッションを張る説明が一般的です。利用者向け文脈で言及される MTProto 规则は、専用の「特別な文法」というより、Telegram 向けの出口を一つのプロキシグループに揃え、暗号化 TCP がそのトンネルを通るようにするという意味合いで使われることが多いです。ノードの種類(VLESS・Trojan 等)が MTProto パケットを正しく中継できるか、sniffing や SNI まわりの挙動が期待と合うかは、接続先によって差が出ます。

「ブラウザは速いのにアプリだけ遅い」は、HTTP(S) が拾われても、TLS の背後の宛先 SNI や、クライアント直のセッションが別ルールに落ちている典型パターンです。redir-host / fake-ip など DNS モードの選択が、MTProto 规则の見かけ上の成否に効く例はコミュニティでよく議論されます。基礎の地図を揃えるには、YAML・Fake-IP とルール分流の解説を併読すると、設定画面の用語と実接続の対応が掴みやすいです。

ルール例(概念スケッチ・実環境で要検証)

実際のクライアントの宛先に合わせてホスト名を足し引きしてください。下記は Clash Telegram 分流の骨格例です。TELEGRAM という select グループを作り、安定したノードだけを入れると運用が楽です。

# Concept only — verify hostnames; replace RULE-SET with trusted sources.
proxy-groups:
  - name: TELEGRAM
    type: select
    proxies:
      - node-stable-1
      - node-backup
      - DIRECT

rules:
  - DOMAIN-SUFFIX,t.me,TELEGRAM
  - DOMAIN-SUFFIX,telegram.me,TELEGRAM
  - DOMAIN-SUFFIX,telegram.org,TELEGRAM
  - DOMAIN-SUFFIX,web.telegram.org,TELEGRAM
  - DOMAIN-SUFFIX,desktop.telegram.org,TELEGRAM
  - DOMAIN-SUFFIX,core.telegram.org,TELEGRAM
  - DOMAIN-SUFFIX,telegra.ph,TELEGRAM
  # Add RULE-SET or GEOSITE if your subscription provides Telegram lists.
  - MATCH,PROXY
ヒント

地域ブロックのないノードに一度だけ乗せてログでヒット行を確かめてから、本番用の Clash 分流を微調整すると安全です。グローバル MATCHDIRECT のままの構成では、telegraph 用に書いた行より先に抜けてしまう、という順序ミスも起きがちです。

TUN、混合ポート、システムプロキシのどれを主にするか

システムプロキシにだけ従うアプリと、独自にソケットを張るクライアントが混在すると、ステータス表示だけが曖昧に「接続中」のまま残る事象に繋がります。TUN モードは、OS から見えるトラフィックを広く Clash 側のルールに乗せやすい一方、他の VPN や仮想アダプタと競合しやすいです。Windows では TUN 周りのトラブルシューティングに沿って適合性を確かめると早いです。

「ポートを開放したか」という観点では、クライアントの設定で HTTP/SOCKS ミックスを参照しているなら、混合ポートの実ポート番号と、OS/アプリが参照している値が一致しているかを最優先で確認する価値があります。ルール以前にトラフィックがコアに届いていないと、いくら MTProto 规则を書いても意味がありません。

DNS、Fake-IP、telegram 名前一貫性

ルールはドメイン名でマッチするため、DNS が返す答えと、実際に張られる接続の宛先にズレがあると、見かけ上ルール通りのはずの通信が別経路に出ます。Fake-IP を使う場合の fake-ip-filter への Telegram 系の入れ方、nameserver-policy による分離は環境差が大きい領域です。詳しいパラメータの意味は ドキュメントの DNS・Fake-IP 節を参照し、手元の GUI の表示と突き合わせてください。

Android・実機の切り分け

モバイルでは、VPN 方式のアプリ、プロファイルごとの分離、省電力によるバックグラウンド切断など、追加の要因が重なります。アプリ単位のプロキシ制御の考え方は、Android アプリ別プロキシの記事と併せて読むと、Clash コアの外側で落ちるパケットを減らせます。ここまでの Telegram 向け手順を試しても症状が残る場合は、まず他アプリ同様にコアのログに通信が届いているか、を分岐点にすると整理が速いです。

切り分けチェックリスト

  1. t.me:招待リンク展開と Web 表示で必要なドメインが、意図した TELEGRAM グループにヒットしているか。
  2. MTProto セッション:同じ出口に揃い、想定外の DIRECT 抜けがないか(ログのヒット行で確認)。
  3. モード:TUN/システムプロキシ/手動のどれを主に使うかを一つに寄せ、二重ルートになっていないか。
  4. DNS:Fake-IP や DNS 上書きと実接続の一貫性。必要なら Fake-IP 解説と照合。
  5. 他ソフト:別 VPN や企業スプリットトンネルが 443 系を奪っていないか。
注意

各サービスの利用規約、居住地域の法規、職場や教育機関のネットワークポリシーはそれぞれ異なります。本稿は一般的なプロキシ設定の説明であり、特定のサービスの利用を推奨・保証するものではありません。

まとめ

プロキシを有効にしても Telegram 接続中表示が抜けない問題は、Clash 分流t.me 系と本丸の telegram.org 系の両方を同じ方針で扱うこと、MTProto 相当の接続を選んだ出口に乗せること、DNS との一貫性を取ること、の三つに整理すると手戻りが減ります。Discord ほど UDP 分流の議論が前面に出ないことも多い一方、TUN や端末固有情報が絡みやすい点は同じく丁寧なログ確認が鍵です。

他の多機能クライアントと比べ、ルール表現とコア挙動の見通しの良さは Clash 系の強みのひとつです。安定した配布物から試す場合は、ダウンロードページで OS に合うパッケージを選ぶと手順が短くなります。リポジトリ上のソースは挙動理解に役立ちますが、実行ファイルの入手はまず配布元を主な入口にすると、UI とコアの対応を追いやすいです。→ 無料で Clash をダウンロードし、Telegram 向けの分流を検証する