Telegram デスクトップが繋がらない？Clash 分流と DNS

デスクトップ IM は「ブラウザより経路が見えにくい」

Telegram デスクトップは、単一の Web ページのように振る舞いません。認証、メッセージ同期、メディア、VoIP、更新チェックなどが別ホストや別プロトコルに分かれ、ブラウザ版と比べてどの通信がプロキシに乗っているかが分かりにくいです。Clash（Mihomo コアを含む）では、これをルールで出口を決め、DNS で名前解決の前提を揃えることで、「つながるときとつながらないときがある」「通知だけ遅い」といった不安定さを減らせます。本稿は AI ツールやソーシャルブラウザ向けの稿と棲み分けし、デスクトップ IMに焦点を当てます。

症状の典型は次のとおりです。起動直後は同期できるがしばらくすると頭打ち、画像とテキストだけ別速度、モバイル公式アプリでは問題ないのに PC 版だけおかしい。多くの場合、ノードそのものより先に一部ホストが DIRECT のままだったり、DNS がアプリの期待とズレて fake-ip と実経路が一致しないことが原因です。まずは「全ノードを総入れ替え」ではなく、接続ログでドメインとルール命中を確認するのが近道です。手順の型は接続ログの見方で扱った切り分けと共通です。

Clash Telegram 向け：ドメインと IP をプロキシへ寄せる

Telegram 周辺でよく登場するのは telegram.org、t.me、cdn.telegram.org、*.telegra.ph などのほか、クライアントのバージョンや地域によって追加のサブドメインが増えます。リモートのルールセットだけに任せると、マージ結果で意図した行より手前の GEOIP や広い DIRECTに吸われることがあるため、確定しているサフィックスはローカルルールの上位に明示します。分流の地盤は国内直通と海外プロキシの分流戦略と同じく「細かい DOMAIN を先、広い GEOIP を後」です。

以下は概念デモです。既存の proxies 名に合わせて置き換えてください。コメントは英語のみとします。

proxy-groups:
  - name: IM-PROXY
    type: select
    proxies:
      - HK-STABLE
      - SG-STABLE
      - DIRECT

rules:
  # Telegram-related — place BEFORE broad GEOIP DIRECT
  - DOMAIN-SUFFIX,telegram.org,IM-PROXY
  - DOMAIN-SUFFIX,t.me,IM-PROXY
  - DOMAIN-SUFFIX,tdesktop.com,IM-PROXY
  - DOMAIN-SUFFIX,telegra.ph,IM-PROXY
  # Add IPs only if you verified ranges; avoid stale lists
  # - IP-CIDR,91.108.0.0/16,IM-PROXY
  # ... GEOIP / MATCH below

IP-CIDR は公式に公開される帯域の変化もあるため、ログで実際に出た宛先を確認してから足すのが安全です。DOMAIN-KEYWORD,telegram のような広い書き方は他アプリを巻き込みやすいので、まず DOMAIN-SUFFIX と接続ログの根拠を優先してください。Clash Telegram 用途では、メッセージ本文より先に落ちるのがCDN や長めのストリーム接続であることが多く、ルールが一つ足りないだけで「たまにしか再現しない」ように見えます。

ポリシーグループ：デスクトップ IM は「切り替わりすぎ」に弱い

インスタントメッセージは TCP セッションの維持と再試行が多く、url-test の間隔が短いとハンドシェイク途中で別ノードへ移り、結果として断続的な失敗に見えます。デスクトッププロキシ用途では、計測間隔を長めにした url-test か Selector で手動固定が現実的です。空港のリモート設定をそのまま信じる前に、マージ後の評価順と重複する DOMAIN 行を一度だけ眺めると、「ノードが弱い」よりルール順のミスに気づけることがあります。

💡

他記事との違い X・Grok 向けの稿はブラウザ上の複数ホストを前提にしています。Telegram デスクトップはネイティブの DNS 解決や QUICの扱いが絡みやすく、同じ「ソーシャル」でも最適なルール順が同一ではない点に注意してください。

DNS 分流：fake-ip と redir-host で「解析ずれ」を潰す

fake-ip モードでは、アプリが最初に受け取る IP が実サーバのものではなく、Clash が割り当てた仮アドレスになることがあります。ルールは正しくても、アプリ側のキャッシュ DNS と Clash の名前空間が食い違うと、「一瞬は届くがすぐ詰まる」「再起動すると直る」といった症状が出ます。対策の方向性は次の二つです。(1) DNS 関連の設定（listen、enhanced-mode、nameserver／fallback）を一系統に揃える。(2) 問題のホストがログ上どのポリシーに落ちているかを確認し、DIRECT 残りならルール不足、プロキシに乗っているのに失敗ならノード側と分岐する。

redir-host（実 IP を返す系の設定）では、見えている IP と実接続の対応が追いやすい反面、解決先が意図せずローカル DNS に逃げると GEOIP ルールの判定がズレます。どちらのモードでも本質は同じで、「ルールは出口」「DNS は名前空間」の二本柱が噛み合わないと、表面症状だけがループします。DNS 分流という言葉で別プロファイルを増やすより、まずはクライアントが TUN またはシステムプロキシで全トラフィックを捕捉できているかを確認する方が費用対効果が高いです。

TUN とシステムプロキシ：デスクトップアプリを取りこぼさない

Telegram デスクトップは、環境によってはシステムプロキシ設定を無視するか、一部ソケットだけ別経路に出ます。TUN モードは OS レベルでトラフィックを Clash に集約するため、こうした取りこぼしを減らせます。代わりに権限や他 VPN との競合が出るため、まずシステムプロキシでログにホストが現れるかを見て、現れなければ TUN を検討する、という順が安全です。

IPv6 が有効な環境では、IPv4 だけプロキシに乗りIPv6 だけが直結していると、不思議な挙動の原因になります。OS の IPv6 設定と Clash 側の ipv6 オプションを揃え、ログでどのアドレスファミリで接続しているかを確認してください。

ログで見るべきこと：不安定さは「ルール」と「DNS」の境目に出やすい

接続ログに、対象ホスト、マッチしたルール種別、選ばれたポリシー名、実際の出口ノードが並んでいれば、その通信がプロキシに入ったかが一度に分かります。期待と違う ルール命中なら YAML の順序を疑い、命中は合っているのに dial tcp や TLS で落ちるならノードやローカルセキュリティ製品を疑います。fake-ip 利用時は、表示 IP が実サーバのものかどうかを頭に置いて読むことが重要です。

詳細なフィールドの読み方は接続ログの記事に任せ、本稿ではIM デスクトップでログが薄く感じるときに、TUN 未使用・プロキシ無視・IPv6 直結の三択を先に潰す、という運用だけ強調します。

⚠️

法令と利用規約 接続先ネットワークのポリシー、居住地域の法規、各サービスの利用規約を順守してください。本文は正当なアクセス権限のある環境で、Clash を用いて技術的な経路を意図どおり揃えるための参考情報です。

まとめ：Clash Telegram は「ルール順・DNS・モード」の三点セット

クロスボーダー向けの IM は、話題性だけでなく接続の再現性が生活の快適さに直結します。ノードを入れ替える前に、ドメインと IP のルールが広い DIRECT より前にあるか、DNS モードと実際の経路が一致しているか、デスクトップアプリのトラフィックが Clash に入っているか——この三点をログで固めると、徒労な設定変更を減らせます。デスクトッププロキシとして Clash を使う場合も、型はブラウザ向けと同じ三角形に立ち返れます。

クライアントの導入や購読の取り込みがまだなら、当サイトのダウンロードページから入手し、購読 URL チュートリアルで土台を整えてから本稿のルールを足すとスムーズです。オープンソースの議論は各プロジェクトの GitHub で追えますが、初回インストールのパッケージはサイト経由で揃えると取り違えが減ります。→ Clash を無料ダウンロードし、Telegram デスクトップの経路を手元で試す