1. 症状と切り分けの軸
まず現象を粗く分類すると、次のようなパターンが多いです。（1）テキストチャットや画像の読み込みは普通なのに、ボイスチャンネルに入るとだけ不安定になる。（2）接続自体はできるが、数分ごとに無音やロボット声が挟まる。（3）アイコン横の表示が接続中やRTC 接続付近で長く止まる。（4）画面共有や Go Live は動くが音声だけが劣化する。
これらはすべて「出口ノードが遅い」だけでは説明しきれず、どの実行ファイルのパケットがどのポリシーに載っているかと、UDP がトンネルに入っているかが鍵になります。HTTP や TCP 中心の通信はシステムプロキシ経由でも追従しやすい一方、WebRTC のメディア面は UDP に依存するため、プロキシ設定と食い違うと「アプリは動くが声だけ死ぬ」が起きやすい構造です。
クライアントの入手は 当サイトのダウンロードページを、設定の全体像は ドキュメントとあわせて参照してください。
2. Discord ボイスが Clash と相性問題を起こしやすい理由
Discord デスクトップは単一プロセスでは完結せず、レンダラやヘルパーが分かれますが、ボイスメディアの多くは本体に近い Discord.exe に紐づくことが一般的です。ドメインルールだけで discord.com や discordapp.com 系を PROXY に寄せても、実際のメディアセッションが別ホスト・別ポートの UDP で張られており、そこが広い MATCH,DIRECT や誤った RULE-SET に飲まれているケースは珍しくありません。
また、ブラウザ版 Discord を使う場合は、ブラウザプロセス名（例：Chrome 系）でルールが決まるため、デスクトップ版と同じ YAML をそのまま当てても挙動が変わる点に注意してください。切り分けでは「いま声を出しているのがどの実行ファイルか」をタスクマネージャとログの両方で確認するのが近道です。
3. プロセス分流とルールの書き方
ルール分流は rules: を上から順に評価します。PROCESS-NAME,Discord.exe,PROXY のように書く例は単純ですが、実務では GEOIP や大きな RULE-SET が先にマッチしてプロセス行に到達する前に決着していないかが成否を分けます。一時的に verbose ログを見ながら、実際にヒットしているルール名をメモしてから順序を調整するのが安全です。
# Example only — process names and policy groups must match your client
rules:
- PROCESS-NAME,Discord.exe,PROXY
# Optional: browser Discord uses the browser process name instead
- MATCH,DIRECTドメインルールとの併用
サブスクの RULE-SET に Discord 向けカテゴリが含まれていても、ボイス用のホストがセットに含まれていない場合があります。そのときは、ログに出たホストを元に DOMAIN-SUFFIX や IP-CIDR を補足するか、しばらく プロセス優先で固定して挙動を確認します。いずれの方法も、第三者サービスへの過度な干渉や規約違反にあたる操作は行わない前提です。
4. UDP・WebRTC とボイス品質
ボイスの送受信は WebRTC が中心で、遅延を抑えるために UDP が使われます。システムプロキシのみ有効で TUN がオフの構成では、UDP がプロキシスタックに乗らず意図せず直結したり、逆に期待したノードを経由しないまま別経路へ出ることがあります。結果として、テキストはプロキシ経由で「速い」ように見えても、メディアだけが別ルートで不安定——という非対称が起きます。
TUN モードを使えるクライアントでは、OS レベルでトラフィックをまとめてトンネルに載せやすくなり、UDP の取りこぼしを減らせる場合があります。ただし TUN はルーティング全体に触れるため、社内 VPN や別のフィルタと競合しやすい点は TUN とファイアウォールの記事で述べているとおりです。二重トンネルになっていないかも合わせて確認してください。
5. TUN とシステムプロキシの使い分け
ざっくり言えば、ブラウザや一部アプリの TCP はシステムプロキシで十分なことが多い一方、UDP を含めて一貫した経路を取りたいときは TUN の検討余地が大きくなります。Discord はその典型で、シグナリングは TCP、メディアは UDP——という二面性があるため、片方だけが意図したポリシーに乗っている状態に気づきにくいです。
切り替え実験をするときは、TUN のオンオフ・システムプロキシ連動・プロセスルールの追加を同時にいじらず、一度に一要素だけ変えてログを比較してください。変更が複数だと、どれが効いたのか判断できなくなります。
6. Discord クライアント側の設定
プロキシ側を整える前後で、アプリ内の設定も確認しておくと手戻りが減ります。バージョンにより名称が変わるため、ここでは一般的なチェック項目に留めます。
- 入力・出力デバイス：既定デバイスが Bluetooth ヘッドセットのマイク／スピーカーに一時的に切り替わっていないか
- QoS（サービス品質）：ルータや回線と相性が悪い場合、オフを試すユーザーがいる（環境依存）
- ハードウェアアクセラレーション：GPU ドライバ周りで音声処理だけ不安定なとき、オフで改善する例がある
- サーバー地域：ボイスリージョンが物理的に遠いと RTT が伸び、途切れに感じやすい
これらは Clash とは独立した要因ですが、「プロキシをオフにしたら直る」場合でも、実はDiscord 側のデバイス選択が原因だったというケースはよくあります。まず素の回線でボイス単体を試し、差分を切り分けると確実です。
7. Clash クライアントで確認すること
Clash Verge や Clash for Windows など、GUI 付きクライアントでは TUN、システムプロキシ、管理者権限、プロファイル選択が画面に出ます。名称は世代で異なるため固定ラベルは避けますが、次の順で見ると抜け漏れが減ります。
- コアと GUI の組み合わせ：古い組み合わせでは UDP まわりの挙動差が出ることがある
- ルール優先順位：
PROCESS-NAMEが評価される前に広いルールで決着していないか - DNS モード：Fake-IP と実解決のずれで、シグナリング用ホストだけ別経路になっていないか
- 他 VPN／フィルタ：Wintun 系や企業エージェントと二重になっていないか
待受ポートや LAN 共有をいじっている場合は、ミックスドポートとファイアウォールの整理も参考になります。ゲームの Steam 記事とセットで読むと、UDP を扱うアプリ共通の考え方が掴みやすいです。
8. 実測で見るべきログ
推測でルールを増殖させるより、ボイス接続を張った直後のログに出る宛先・プロトコル・プロセス名を一度スクリーンショットやメモで残す方が再現性が高いです。UDP の行がまったく出ない、出てもポリシーが DIRECT のまま、といった事実だけでも次の手が決まります。
確認は、同じサーバー・同じ相手・同じ時間帯で繰り返し、体感に加えて Discord の接続情報や OS のネットワークメータが取れる範囲で参照するとよいでしょう。Wi‑Fi の電波状況や省電力設定による NIC のスリープも、一見プロキシのせいに見える遅延の原因になります。
9. 症状対照表
| 症状 | ありがちな原因 | 先に試すこと |
|---|---|---|
| テキストは普通、ボイスだけ途切れる | UDP が別ポリシー／直結 | ログで UDP 行を確認、TUN またはプロセスルール |
| 接続中のまま進まない | シグナリング TCP とメディア UDP の経路不一致 | 同一プロファイルで両方のログを比較 |
| ブラウザ版だけ不具合 | ブラウザプロセス名でルールが変わる | PROCESS-NAME をブラウザ用に分ける |
| 特定ノードだけ悪化 | UDP 向けの輻輳や NAT 挙動 | 別ノードで比較、ピーク時間帯の変更 |
11. まとめ
Discord のボイスが Clash オン時だけ不安定なら、テキストとメディアでプロトコルと経路が分かれている可能性を最初に疑うのが近道です。Windows では プロセス分流で Discord.exe を明示し、UDP が期待するポリシーに載っているかを TUN とシステムプロキシの両面からログで確認する。変更は一つずつ、Discord アプリ側のデバイス設定も同時に見る——この順序が 2026 年時点でもいちばん再現性の高い切り分けです。
同種ツールと比べて Clash 系は接続とルールの対応を追いやすく、試行のたびに「何が効いたか」を積み上げやすいのが強みです。ノード品質と帯域が揃えば、ソーシャル用途の通話も含めて日常利用が安定しやすくなります。