📖 チュートリアル 2026年4月15日 ⏱ 約17分で読めます

Discord の音声が途切れる：Clash の UDP 分流と直結例外を段階実測（2026）

Discord のボイスチャットだけがカクつく、途切れる、サーバーから落ちる、といった症状は、ゲームやコミュニティ利用で非常によく聞かれます。同じ PC で Clash を常時オンにしている場合、原因は「ノードの品質」だけとは限らず、UDP を含む RTC 系トラフィックが意図しない出口に流れている、あるいはプロキシ経路がリアルタイム通信に向いていない、というケースが多いです。本稿は、分流ルールと直結（DIRECT）の例外をどう置くか、接続ログで何を見るか、DNS や TUN とどう揃えるかを、コピーして調整できる YAML 例つきで段階的に整理します。Steam／Epic 向けのストア分流や Zoom／Teams 向けの会議分流とは対象アプリとプロトコル特性を分けた、Discord 音声特化の実用ガイドです。

まず確認：Clash を外したときだけ直るか

作業の最初にやるべきなのは、Clash を事実上バイパスした状態で Discord の音声が安定するかを見ることです。クライアントを終了する、Direct 相当のモードにする、あるいは Discord だけ OS のファイアウォールや別ツールの例外に近い形で直結させる、など方法はいくつかありますが、共通しているのは「プロキシの経路を外したら症状が消える」かどうかです。消えるなら、Discord 本体のバグやヘッドセットの不良より先に、ルール・ノード・UDP の扱い・DNSのどれかを疑うのが合理的です。

消えない場合は、回線のジッター、Wi‑Fi 干渉、Discord 側のメンテナンス、地域レベルのブロックなど、プロキシ以外の要因が前面に出ます。ここではClash が絡むときに効く切り分けに絞ります。トンネル型 VPN との違いやレイヤの感覚は Clash と VPN の比較記事も参照してください。

なぜ Discord 音声は Clash と相性問題を起こしやすいか

Discord のボイスは、テキストや画像 CDN と同じ「ブラウザ的な TCP だけ」では完結しません。低遅延のメディア転送に UDP が使われる場面があり、これがいわゆる RTC まわりの挙動に近いです。UDP は「届かなくても再送を積み上げる」より「遅延と損失に素直に反応する」側のプロトコルなので、遠回りのプロキシやジッタの大きいノードに乗ると、体感では一瞬で「途切れた」「ノイズが乗った」に変換されやすいです。

さらに、ルール型プロキシではドメインや IP ごとに出口を変える設計が基本です。Discord は複数のホスト名とエッジサーバを行き来するため、テキスト用だけルールを書いて音声用が別出口に流れる、名前解決と実接続の見え方が食い違う、といったズレが起きやすくなります。だからこそ、固定リストを盲信せず、ログに出た宛先を正に育てる姿勢が重要です。

UDP とノード：プロキシが「通す」とは限らない

利用している購読やノードによっては、TCP のウェブ閲覧は快適でも UDP が制限されている、あるいは中継の実装都合で UDP が不安定、ということがあります。その場合、テキストチャットは普通に動くのにボイスだけが荒れる、というパターンが出ます。切り分けとしては、(1) 別のノードに変えて同じ操作を繰り返す、(2) 可能なら UDP 対応を謳う近距離リレーを試す、(3) それでもダメならDiscord 関連を一時的に DIRECTにして比較する、の順が扱いやすいです。

ここで注意したいのは、「UDP をオフにすればよい」という単純話ではない、という点です。問題は UDP そのものではなく、UDP を載せる経路の品質と整合です。ルールで意図したグループに載っているか、そもそもプロキシに載っているかをログで確認することが先です。

システムプロキシと TUN：Discord プロセスがどこを通るか

デスクトップの Discord は独立プロセスで動き、OS のプロキシ設定を常に尊重するとは限りません。ブラウザ版は問題ないのにアプリ版だけボイスが不安定という報告も、経路の取り方の差から説明できることがあります。大きく分けると次の二つです。

システムプロキシ：導入が簡単な反面、UDP や特定ポートがプロキシに乗らない経路を取ると、ルールを足しても効かないことがあります。
TUN モード：より下位でトラフィックを取り込み、カバー範囲は広がりがちです。一方で DNS や fake-ip、他社 VPN との競合も起きやすくなります。仕組みは TUN モードの解説を参照してください。

実務では、ボイス品質を追う前に接続ログに Discord 操作時のフローが現れるかを確認し、現れないなら取り込み方を変える、という順が安全です。

ログを正にする：ボイス中に出るホスト名を拾う

Discord が使うホスト名は更新や地域スケジューリングで変わり得ます。したがって、ネット上の「完全な固定リスト」をそのまま信じるより、自分の環境の Clash ログに出た名前をルールに反映する運用が現実的です。ボイスチャンネルに入る・抜ける・画面共有を試す、といった操作をしながら、失敗や劣化の瞬間の宛先とヒットしたルール行をメモしてください。

目安としてログに現れやすいのは、discord.com、discordapp.com、discord.gg、discord.media、discordcdn.com、gateway.discord.gg などの系統です。ただし例示に過ぎないので、足りないホストは必ずログから追加してください。ルールの順序や no-resolve の扱いはカスタムルール完全ガイドと併読するとミスが減ります。

分流ルールの骨格：直結例外と固定ノードの二段構え

以下は構造の例です。PROXY_DISCORD は自分の proxy-groups に実在する名前に置き換えてください。丸ごとコピーして万能設定にするのではなく、自環境のログに合わせてドメインを増減させる前提です。グループの型や名前付けは proxy-groups のガイドも参照してください。

# Example only — replace PROXY_DISCORD with your proxy-groups name
rules:
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - PROCESS-NAME,Discord.exe,PROXY_DISCORD
  - PROCESS-NAME,Discord,PROXY_DISCORD
  - DOMAIN-SUFFIX,discord.com,PROXY_DISCORD
  - DOMAIN-SUFFIX,discordapp.com,PROXY_DISCORD
  - DOMAIN-SUFFIX,discord.gg,PROXY_DISCORD
  - DOMAIN-SUFFIX,discord.media,PROXY_DISCORD
  - DOMAIN-SUFFIX,discordcdn.com,PROXY_DISCORD
  - DOMAIN-SUFFIX,gateway.discord.gg,PROXY_DISCORD
  - GEOIP,CN,DIRECT
  - MATCH,DIRECT

PROCESS-NAME は OS ごとに表記が変わります。Windows なら Discord.exe、macOS なら実行ファイル名が異なることがあるため、クライアントのログ画面やタスクマネージャで実名を確認してください。音声だけ直結にしたい場合は、上記の Discord 系の行を DIRECT に置き換え、他のトラフィックは従来どおり別グループへ、という切り方もよく使われます。国内帯の GEOIP,CN,DIRECT をどう置くかは、自分の回線と購読の方針に合わせてください。

DNS と fake-ip：ルールに書いたドメインと解決結果が一致しているか

「テキストは行けるのにボイスだけおかしい」背景に、DNS の食い違いがあることは珍しくありません。OS の DNS、ブラウザの DoH、Clash 内蔵 DNS が同時に動いていると、ルールがマッチしたつもりのドメインと、実際のコネクション確立で使われた情報がずれることがあります。fake-ip を使う構成では、no-resolve やルール順、DNS フェイルオーバをセットで見直す必要が出やすいです。

切り分けのコツは、一度にいじるのを一か所に絞ることです。DNS だけ変えて効果を見る、ルールだけ変えて効果を見る、と分けると原因が追いやすくなります。HTTPS まわりで奇妙な挙動が出る場合は、sniffing と DNS の検証記事も参考になりますが、Discord ボイスの主戦場はドメインと UDP の方に寄ることが多いです。

動作モード：Rule・Global・Direct で位置づけを切り替える

日常運用は Rule が基本です。短時間だけ Global に近い状態で試すと、「ルール不足なのかノード品質なのか」を切り分けしやすくなります。ただし常時 Global は国内サイトまで遠回りになりがちなのでおすすめしません。Direct はベースライン用に、Clash を事実上オフに近い状態で音声品質を測ります。ルールを修正したあとは、意図した行にヒットしているかを必ずログで確認してください。

推奨の実測ステップ（チケット用にメモを残す）

変数を減らす：他社 VPN やブラウザ拡張のプロキシを止め、Clash だけにする。
ベースライン：Direct 相当でボイス品質を確認し、改善幅を把握する。
取り込み方：システムプロキシと TUN を切り替え、Discord のフローがログに出るか比較する。
ルールとノード：同一ノードに固定しつつ、Discord 系ドメインと PROCESS-NAME をログに基づき追加する。
UDP の疑い：別ノードでも再現するか見る。改善するなら経路品質の問題寄り。
直結例外：必要なら Discord だけ DIRECT に落として品質とプライバシーのバランスを決める。

この手順は Zoom／Teams 向けの会議記事と同じく、ログ駆動の骨格です。観察対象がビデオ会議からボイスチャットに変わるだけで、UDP の比重が上がる点に注意してください。

よくある質問

ドメインルールを足したのにボイスが改善しない

音声が別ホストや IP 直撃で流れている、PROCESS-NAME が効いていない、より手前の広いルールに食われている、などが考えられます。ログのヒット行と宛先を確認し、順序と表記を直してください。

テキストは行けるのにボイスチャンネルだけ入れない

UDP や特定ポートがプロキシに乗っていない、ノードが UDP に弱い、DNS の結果が会話用エッジと合っていない、などを疑ってください。TUN への切り替えやノード変更、短時間の Direct 比較が有効です。

ゲームと同時に Discord を使うとだけ悪化する

帯域争いや CPU 負荷もありますが、ルール面ではゲーム用の広い DOMAIN-SUFFIX や PROCESS-NAME が先にマッチして意図と違う出口に流している可能性もあります。ログで同時刻のヒットを確認してください。Steam／Epic 向け分流のルールと順序が干渉していないかも見ます。

まとめ

Discord のボイスチャットが Clash 利用時だけ不安定になるときは、RTC／UDP を適切な出口に載せることと、分流ルール・DNS・TUN／システムプロキシの取り込み方を揃えることが中心です。固定リストよりログを正にし、必要なら 直結例外でボイスだけをバイパスする判断も現実的です。

クライアントの入手は本サイトのダウンロードページを第一にすると、記事との突き合わせもしやすくなります。基本操作はチュートリアルで押さえ、本稿の手順で Discord 向けのルールを足してみてください。ルールの見える化と切り替えのしやすさは Clash の強みです。他ツールよりも「どのホストがどの出口に流れたか」を追いやすい点は、ボイス品質の切り分けでもそのまま強みになります。→ Clash を無料ダウンロードし、Discord 向けの UDP・分流を試す