Telegram はなぜ複数ホストと QUIC に分岐しやすいか

Telegram は表向けひとつのメッセンジャーに見えますが、内部ではチャット・メディア・アップデートチェックがtelegram.org 系ホスト／API、短縮の t.me、画像・動画配信用の広い CDN を跨ぐ名前へ分散しやすく、環境によっては優先すると判断した QUIC（UDP） と従来の TCP／HTTPS が混在します。ここが別ストラテジ・別ノード、あるいは「HTTP だけ通して UDP が直結」などの非対称になると、アプリ画面上はログイン状態を保っているのに同期や一覧取得だけ終わらない様子になります。前列の GEOIP／広い RULE-SET が先にヒットすると、「Telegram はプロキシに載っているはず」なのに片側だけ直行に落ちている、という取りこぼしが増えやすいです。バイトダンス CDN 系でのドメイン分流 と同種の論点がありますが Telegram は QUIC の比重が高く、単に「CDN 名を足す」だけでは足りないケースがあります（仕様変更は定期的に起こるので自分の環境でのライブログ前提です）。

ルール順の共通原則は ルール分流のベストプラクティス のとおり。MATCH に任せず、Telegram と判断した名前空間だけをひとつのポリシー（例：TG_IM_STABLE）に束ねる流れです。許可されていないサービスへの迂回には使わないことは言うまでもありませんが、許可済み環境でもUdp／Quic のレイヤーを疑うほど体感が読みやすくなります。

典型症状「接続中」とログで見える取りこぼし

代表例です。(1) デスクトップでウィンドウは開いたがチャット一覧だけがぐるぐる、メディアのみ欠ける。(2) Web（web.telegram.org）だけ不安定で、スマホのモバイル回線では普通——このときブラウザのシステムプロキシと、OS が握る UDP のパスの差が出やすいです。(3) 音声通話だけ落ちやすく、チャットだけは問題ない。(4) 更新直後のみ数分間だけ「接続中」が収まらない——アップデート取得先が別名で、広いリストにのみヒットしていた、など。接続ログの timeout／TLS の切り口で、Quic を含む失敗か純 HTTPS かを分けると次のホスト追加が早いです。

ℹ 観測のヒント：失敗行のタイムスタンプより少し広く（前後数十秒）、同一時刻に出た異なるホストの列を眺め、(a) DNS 名前、(b) 実転送ポートが TCP だけか QUIC か、(c) ストラテジ名、(d) ノード名の四種をセットで並べます。

telegram.org・API・CDN・共有リンク

固有名は変わり得ますが、運用上のハブとしては例えばtelegram.org とそのサブドメイン、`t.me` 共有、クライアントが読みにいく構成情報やアップデート用の名前、ユーザーアイコンなどを配る広い CDN 系が現れやすく、どれも同一の TG_IM に束ねられるかログで確認すべき単位です。長大なリストをすべて REJECT と衝突させないためにも、「Telegram と分かった名前だけ」を前段へ置く方針です。Microsoft 依存の別稿のように協業 SSO は絡みにくい一方、CDN の「似た名前の別サービス」を誤結合しないよう広すぎる DOMAIN-KEYWORD は避けるのが安全です。

QUIC／UDP と TUN：ゲームより IM 側の盲点

ゲーム UDPは Steam 向け UDP／TUN 記事 で扱いやすく書かれていることが多いですが、メッセンジャ側の QUIC もレイヤとしてはゲーム類似の「ポート・プロトコルを含めた転送経路」を要することがあります。TUN が有効 で OS 全体から拾えているときと、単に HTTP／SOCKS がブラウザにだけ効かせているときで挙動が分裂しやすいです。音声通話のみ途切れるなら、その部分が UDP で別出口に割れていないか疑ってください。また クライアントタイプによって TUN とプロセスの親子関係が違うため、ログの並べ方だけで「大丈夫なはず」が崩れることがあります。

web.telegram.org とネイティブ／Electron

ブラウザ版は CSP やサービスワーカの影響もあり、アプリとは異なるセットのホストに触れることがあります。システムプロキシのみの環境では十分でも、別クライアントのみが 分アプリ方式で取りこぼす、という切り口もありえます。SwitchyOmega 等のブラウザ拡張との二重化にも注意してください。

tdata の意味（ログイン状態とレイヤーを取り混ぜない）

Windows／一部クライアントではセッションを tdata ディレクトリに保持することが知られています。ここにあるのはログイン状態とローカル暗号済みコンテキストであり、ネットワーク上の経路とは別レイヤです。画面が「接続中」のままでも削除して直る場合はキャッシュ問題、直らずログに QUIC だけ失敗があるなら経路問題——と問題のレイヤーを分けてからtdata の可否を考えると迷いません。

単列 TG_IM に束ねるルール例と MATCH 順

名前は環境ごとに付けたいですが、グループTG_IM_STABLE を一つ用意し、その上に許可済みノードだけを並べます。以下は概念例であり、FQDN とクライアント更新に合わせて必ず差し替えてください。MATCH より前に、この束だけを細く並べます。

rules.yaml（例：検証のみ／本番は実ログベース）

# Telegram core + shorthand + QUIC-capable egress; tighten FQDNs from your logs.
rules:
  - DOMAIN-SUFFIX,t.me,TG_IM_STABLE
  - DOMAIN-SUFFIX,telegram.org,TG_IM_STABLE
  - DOMAIN-SUFFIX,tg.dev,TG_IM_STABLE
  - MATCH,PROXY_OR_DEFAULT

QUIC がノード側で遮断されていて Tcp の HTTPS だけが通りやすい場合でも、画面上は Tcp のみでも動く構成が多いので、まず Tcp だけでも同一ストラテジに揃い切ったか確認し、そのあと音声や大容量のみが落ちるなら QUIC 経路へ踏み込みます。もし GEOIP が先で国内へ直行してしまうなら GEOIP と明示ルールの順を見直してください。

Slack／協業 SaaS と被らせないときの境界

Discord アプリ向け分流や Slack と slack-edge を束ねる稿と干渉しやすいのはCDN の共通サフィックスだけを丸ごと同じグループへ入れた場合です。協業ワークフローを切らずに Telegram を使うならば、ルールセットの命名とストラテジをサービス単位で分離し、MATCH 側の広いリストを後ろへ残します。

DNS・fake-ip・IPv6 と証明書に見える欠陥

fake-ip と DoH が二重のとき、画面上は証明書エラーにも見える非同期状態になります。また IPv6 だけ直行していると「一部の名前だけ妙に遅い」ことがあります。Telegram が触る名前をログで列挙し、それに対応する名前解決の一本化が先です。Web ダッシュボードで接続一覧を並べられるクライアントなら、フィルターに telegram を掛けると再確認しやすいです。

⚠ コンプライアンス：Telegram とその API の許諾されていない自動化／巡回、地域・職場方針で禁止される利用形態は対象としません。本稿は認められた環境で経路の一貫性を高めるために、ルールの並べ替えやログの読み取りを整理するだけです。

許可利用の前提チェックリスト

  1. このネットワークで Telegram が許可
  2. 症状に同期したログから FQDN・TCP と QUIC を列挙し、TG_IM 単列へ足すべき名前を決める。
  3. MATCH と GEOIP より前方に Telegram 向け細いルールを置けているか確認する。
  4. TUN の有効／無効とブラウザのみでの A／B で取りこぼしが変わるか見る。
  5. DNS と fake-ip、IPv6 とノード許容を揃える。
  6. 音声や大項目だけダメなときは QUIC／UDP とノード側の許可を確認する。

「接続中」は体感ベースだけでは原因が広がりすぎるラベルなので、上の並びどおりログの列だけで一次切り分けできると復旧までが短くなります。

まとめ

Telegram の「ずっと接続中！」は単一ホストへ ping が通れば解決、という問題に還元しにくく、多くの場合複数名前と QUIC／Udp のレイヤでの出口ずれです。単列 TG_IM と 明示ルールの前方配置、必要なら TUN と DNS を揃えたうえでの再計測 が再現の鍵になります。協業チャットとは別セットで整理しておけば運用ミスによる重ね掛けも減らせます。

→ Clash を無料ダウンロードし、「Telegram 用の細いポリシー」をサブプロファイルで試せば、MATCH の巨大リストを触らずとも改善を確認しやすいです。許可済み環境での快適さを、自分の名前解決ログとセットで調整してください。