Discord が繋がらない、ボイスチャンネルだけ途切れる？プロセス・UDP・ドメインの三本柱で見る Clash TUN と mihomo のドメイン分流（2026）

1. なぜ「システムプロキシだけ」では足りないのか

Windows や macOS の「システムプロキシ」は、多くの場合HTTP や HTTPS を尊重するアプリに効きます。一方で、Electron 系のデスクトップ版は設定によって一部の通信だけ OS のプロキシ表を見ずに出ていくことがあり、ブラウザで discord.com が開けても、ネイティブ部分が別経路に落ちる、というギャップが起きます。

さらに決定的なのがUDPです。Discord のボイスや画面共有まわりは、ネットワーク条件に応じてUDP を優先し、環境によっては TCP にフォールバックしますが、前者が意図しない経路やフィルタにさらされると、体感では「入室直後は聞こえるが数秒で無音」「パケット損失表示が常時赤」といった症状に化けます。HTTP プロキシだけではこのレイヤを一括で扱えないため、仮想インタフェースでスタックに介入する TUNが議論の中心になります。

つまり整理すると、ドメイン単位の策略（どの出口へ出すか）と、その策略が実際に評価される経路（プロセス・プロトコルごとコアに届くか）はセットで考える必要があります。TUN モードの解説で触れているとおり、TUN は万能ではありませんが、Discord のような「ブラウザとデスクトップ」「TCP と UDP」が混在するサービスでは、比較の価値が高いです。

2. 症状の切り分け：Web・API・ゲートウェイ・メディア

まずテキストチャットやサーバー一覧は普通なのに、ボイスルームに入ると不安定なら、表側の discord.com よりもメディア配信やリージョン別ホスト、あるいはUDP の品質を疑う段階です。逆にそもそもログインできない・更新が進まないなら、updates.discord.com やインストーラ周辺、証明書検証、DNS の汚染など、より手前のレイヤが混ざります。

ゲートウェイ（WebSocket）とボイス（UDP）は別物に近いです。前者が安定していても後者だけ劣化する典型は、キャンパス Wi‑Fi のUDP レート制限や、セキュリティ機器による特定ポート帯の優先度低下です。Clash 側では「どのドメインをどのノードへ送るか」を整えても、物理回線の UDP が壊滅しているケースでは改善幅に限界があります。現実的には、有線接続への切り替えや別時間帯の比較を同じチェックリストに入れておくと誤診が減ります。

ルールの基本は ルールルーティングと サブスクリプション導入に共通します。以下では Discord 特有の「名前の束ね方」と TUN の組み合わせに絞ります。

3. TUN が効く場面：プロセスと UDP を同じテーブルに載せる

TUN モードを有効にすると、OS のルーティングテーブル上で仮想アダプタ宛てのトラフィックが Clash / mihomo コアに吸い上げられ、そこでルール評価が行われます。HTTP プロキシを知らないプロセスでも、経路としてコアを通過しさえすれば同じ rules: に乗せられる、というのが実務上のメリットです。

Windows では UWP やループバックの例外が絡むことがあり、当サイトの TUN と UWP・ループバックの稿と併読すると抜け穴を減らせます。macOS ではネットワーク拡張の許可や、Verge 系 GUI の既定トグルが絡みます。macOS での Verge Rev 初回設定で触れている「システムプロキシだけで足りるケース／TUN が要るケース」の判断枠組みを、そのまま Discord に当てはめてください。

TUN をオンにした瞬間に全トラフィックが代理出口へ出るわけではなく、最終的には購読テンプレートの rules: と MATCH 行が支配します。したがって、TUN を有効化したうえで Discord 向けの DOMAIN 束ねを足すのが王道です。国内ドメインまで誤って海外出口に流さないよう、広い GEOIP より上に具体的なサフィックスを置く順序も忘れないでください。

4. ルールに載せたいドメイン空間（Discord / CDN）

インフラ側のホスト名は改修で変わり得るため、手元のログやクライアントのデバッグ表示に出た名前を正としてください。それを前提に、多くの環境で繰り返し登場しやすい出発点として次を挙げます。discord.com（Web と API の表側）、discordapp.com（レガシー名だがログや旧 URL に残ることがある）、discord.gg（招待リンクのホスト）、discord.media、discordcdn.com / cdn.discordapp.com（アイコン・添付の取得）、media.discordapp.net（メディアプロキシ）、gateway.discord.gg（リアルタイムゲートウェイ）などです。

ボイス品質の問題では、ログ上はドメインではなくIP と UDP ポートの組として現れることがあります。その場合でも、名前解決の段階で意図したノードの DNS を通しているか、fake-ip とスニッファの組み合わせでルールが空振りしていないかを先に潰すと、あとから見たときの再現性が上がります。購読ルールセットに「Discord 用」の束が既に入っているなら、重複を増やす前に評価順と策略名を確認するのが安全です。

Steam のストアと CDN の分離を扱った Steam 向け記事とは対象が異なりますが、「UI と実データ取得が別ホスト」という発想は共通です。Discord でもアバターや埋め込みの取得先がルールの外に残ると、一見ランダムなタイムアウトに見えがちです。

5. mihomo ルール例：専用策略の上に DOMAIN を置く

実務では Discord 専用の策略グループを一つ切り、低遅延のノードを手動選択できるようにしておくと運用が楽です。自動選択系は便利ですが、ボイス中に出口が頻繁に変わると再接続が走りやすいため、VC を常用するなら固定に近い運用も検討してください。

以下は構造の例です。プロキシ名は環境に合わせて置き換えてください。

# proxy-groups: pick a low-latency node for Discord stack
proxy-groups:
  - name: DISCORD
    type: select
    proxies:
      - NODE-A
      - NODE-B
      - DIRECT

# rules: place Discord suffixes above broad MATCH / GEOIP
rules:
  - DOMAIN-SUFFIX,discord.com,DISCORD
  - DOMAIN-SUFFIX,discordapp.com,DISCORD
  - DOMAIN-SUFFIX,discord.gg,DISCORD
  - DOMAIN-SUFFIX,discord.media,DISCORD
  - DOMAIN-SUFFIX,discordcdn.com,DISCORD
  - DOMAIN-SUFFIX,discordapp.net,DISCORD
  - DOMAIN,gateway.discord.gg,DISCORD
  - MATCH,PROXY

実際の購読では RULE-SET やプロバイダ定義に寄せることも多いですが、追記した行が評価ブロックの末尾に沈んでいないかは毎回確認してください。また、Discord は利用規約とローカル法令のもとで利用する前提であり、本稿は正当な利用の範囲で自宅や契約ネットワークの経路を整理するための一般知識に限ります。

6. DNS・fake-ip・スニッファ：名前と実接続のずれ

fake-ipを使う構成では、クライアントが握っている IP と、ルールが参照するドメイン情報の間にズレが生じやすくなります。DOMAIN 行を増やしても、評価時点でホスト名が取れていないと策略に乗らず、結果として DIRECT のまま別経路に出る、というパターンが起きます。

ここで役立つのが スニッファ（sniffer）です。mihomo 系では TLS の SNI などから実名を復元し、ルールの再評価に回せます。詳細キーはバージョン差があるため、手元のドキュメントとリリースノートを正としてください。DNS まわりの二正面の考え方は Claude 向けの DNS 稿とも通底します。

さらに、一部ブラウザやアプリが DNS over HTTPS を独自に使う場合、OS の resolver 設定と Clash の DNS セクションが別物として動くことがあります。症状がブラウザとデスクトップ版で違うときは、その差分も疑ってください。

7. 実測手順：接続確認とボイス品質の見方

次の順で進めると抜け漏れが減ります。（1）TUN をオフにした状態で、システムプロキシのみオンにし、Discord デスクトップの「接続テスト」や同等の表示でベースラインを記録する。（2）TUN をオンにし、同じテストを繰り返してゲートウェイ RTT とパケット損失がどう変わるかを比較する。（3）コアログで gateway.discord.gg やメディア系サフィックスが意図した策略名にマッチしているかを確認する。（4）ボイスチャンネルで他者と相互試験し、ミュート解除時のノイズや画面共有のフレーム落ちが回線由来か出口由来かを切り分ける。

ログに繰り返し現れる未登録ホストがあれば、DOMAIN-SUFFIX で足し込みます。一方で、データセンター系の出口 IP自体がボイスサーバ側で不利に扱われることもあり、ドメインは正しくても品質だけ悪い、というケースはノード種別を変えて比較するのが現実的です。自動フェイルオーバのチューニングは url-test / fallback の稿も参照してください。

検証は短時間で済ませず、ピーク時間帯と深夜の二点を取ると、キャリアの UDP 混雑の影響を切り分けやすくなります。社内回線ではセキュリティポリシーが優先されるため、技術的に可能でも運用上禁止されている場合があります。その場合はネットワーク管理者への相談が先です。

8. つまずきとコンプライアンス

第一に、discord.com だけを足して満足することです。表側は通ってもメディアやゲートウェイが別サフィックスのまま残ると、テキストは生きてボイスだけ死ぬ、という状態が消えません。

第二に、TUN を有効にしたのに特定プロセスだけ迂回するケースです。Windows の例外アプリ、他社 VPN の競合、企業デバイス管理ポリシーなどが典型です。UWP まわりは前述の専用稿を当ててください。

第三に、サービス利用規約や法令に反する利用を助長する内容は本稿に含めません。Discord の利用条件、および所在国・契約回線のポリシーを順守してください。

9. まとめ

Discordの不調は、HTTP プロキシだけでは届かないプロセスと、UDP を含むリアルタイム経路、そして分散したドメイン空間が重なって起きます。Clash TUNでスタックに介入しつつ、mihomo のルールで Discord / CDN 系を専用策略に揃え、DNS・fake-ip・スニッファで名前と実接続の策略を一致させる——この三層は、2026 年現在も検索ニーズの大きい「ブラウザは開くがクライアントや VC が怪しい」系の相談に対して、再現性のある対応の骨格になります。

ホスト名は変わり得るため、最終的には自分のログに出た名前を正としてルールを足し込む運用がいちばん確実です。同じ Clash 系でも GUI とコアの世代で既定値が異なるため、安定したクライアントから揃えたい場合は、 → 無料で Clash をダウンロードし、快適な接続体験を試す ところから環境を整えるのがおすすめです。