症状の型：テキストは通るが音声だけ不安定
まず症状を言語化しておくと切り分けが速くなります。ギルド一覧やチャンネル本文、埋め込み画像の読み込みは問題ないのに、ボイスチャンネルに入るとすぐ落ちる、相手の声だけ欠ける、片方向だけミュートに近い、ping 表示は低いのに実体感がガタガタといった報告は、ネットワークのどこかで UDP セッションの品質が崩れている可能性を示唆します。Clash を挟むと典型的なのは、ブラウザやデスクトップアプリが OS の HTTP プロキシ設定を見ている TCP は意図どおり出口へ向かう一方、UDP をプロキシ経由に載せられない／別ルールに落ちるケースです。逆に TUN でスタック全体を覆っていれば UDP も同じルーティング決定に乗りやすくなりますが、そのぶん例外ホール（分割トンネル）の書き方やローカル帯域の除外を誤ると、かえって競合が起きることもあります。
なぜ UDP が焦点になるか
多くのユーザー向け説明では「Discord は暗号化された通信を使う」とだけ語られますが、プロキシ運用の観点では TCP と UDP を別々に考える必要があります。音声や一部のリレーは UDP 上のパケット交換に依存し、環境によっては ホールパンチや ICE に近い挙動が絡みます。Clash Meta（Mihomo） では、ノードの種類や購読側の実装によって UDP の中継可否が異なるため、「同じ出口名でも TCP だけ安定して UDP は落ちる」ことがあります。relay（双跳） で UDP をどう扱うかは relay チェーン記事 に詳しいので、ボイス品質に効くノードを選ぶ前に、そもそも UDP がプロキシに到達しているかをログで固めると迷走しにくくなります。
TUN とシステムプロキシ：何を捕捉するか
システムプロキシ だけを有効にしている構成では、HTTP/HTTPS スタックに載るアプリケーションは比較的追いやすい一方、UDP をそのまま同じ経路へ載せない実装もあります。Discord のデスクトップアプリがどのトランスポートで音声を送っているかはバージョンや地域によって見え方が変わり得ますが、トラブル時の第一歩は「プロキシを無視して DIRECT に落ちていないか」「意図せず国内回線へ直行して NAT やキャリアの制限と衝突していないか」を確認することです。TUN モードは仮想インタフェース経由で OS のルーティングに介入し、アプリがプロキシ設定を読まなくても多くのフローを覆えるため、UDP まで含めて一本のルール集合で語りやすくなります。Linux デスクトップで systemd と併用する例は Linux・Mihomo・TUN 記事 が参考になります。導入時の共通の注意として、既存 VPN や企業ゼロトラストと二重にトンネルを張るとレイテンシが跳ね上がることがあるため、併用時はどちらを上位にするかを意識してください。
目安：「Web 版 Discord はマシだがアプリ版だけおかしい」「ブラウザの別タブは安定だがボイスのみ不安定」など、捕捉経路が違う症状は TUN とシステムプロキシの切り替え比較で手掛かりが増えやすいです。
UDP がプロキシに載っているかを見る
Mihomo 系のダッシュボードや接続ログでは、エントリに network: udp 相当の表示がある場合があります。実際のラベルはクライアントのスキン依存ですが、同一ホスト名で TCP と UDP が別ポリシーに割り当てられていないかを見比べると有益です。discord.com や discordapp.com などの DOMAIN-SUFFIX をルールで揃えつつ、音声が参照する CDN エッジ や リージョン依存ホスト がログに追加で現れたら、その名前も段階的に追記します。購読ルールが古い GEOIP だけに依存している場合、実 IP の所属国とサービスの想定が食い違い、DIRECT に落ちた UDP だけが目に見えない経路で不安定になることがあります。Sniffer で HTTPS のホストを復元する話は Sniffer 記事 が中心で、UDP そのものよりドメイン単位の整合を取りたいときに併用します。
ルール順と「discord をどこに書くか」
Clash 系は上から評価されるため、広い MATCH や粗い DOMAIN-KEYWORD が先にあると、細かく書いた DOMAIN-SUFFIX,discord が到達しないことがあります。症状が「一部アプリだけ」であっても、実際には リストの遥か上方で別ポリシーに吸われているだけ、というのは日常茶飯事です。運用上は、ログで実際に出た名前をメモし、そのサフィックスを明示的に上段へ移すか、競合する広ルールを見直します。PROCESS-NAME で Discord.exe 等に絞るやり方は強力ですが、名前の綴りやパスが環境で異なるため、まずは DOMAIN ベースで当たりを付けたうえで補助に回すと安全です。Windows 全体の初期セットアップは Windows 向けセットアップ記事 と併読すると、GUI と YAML の対応が掴みやすくなります。
# Example sketch: place Discord-oriented rules ABOVE broad catch-alls
rules:
- DOMAIN-SUFFIX,discord.com,YOUR_PROXY_GROUP
- DOMAIN-SUFFIX,discordapp.com,YOUR_PROXY_GROUP
- DOMAIN-SUFFIX,discord.gg,YOUR_PROXY_GROUP
# ...then subscription catch-GEOIP / MATCH rules below
上記は説明用のスケッチであり、実際に必要なサフィックスは接続ログに従ってください。YOUR_PROXY_GROUP は購読ファイルで定義されているポリシー名に置き換えます。国内／国外どちらへ寄せるかは利用規約と居住地域の法令に従い、本稿では特定の出口を推奨しません。
DNS（FakeIP・DoH）とルールの矛盾を潰す
UDP が「変」と感じる局面の一部は、実は 名前解決の結果 と ルール評価の前提 が一致していないことに根差します。fake-ip を使う構成では、クライアントに返るアドレスと、ログに現れる接続先の見え方が読み手を試すことがあります。DoH や nameserver-policy を細かく切っている場合も同様で、Discord が参照するホストが 意図しないリゾルバ で解けていると、TCP だけ偶然うまくいき UDP だけ別セグメントへ向かう、といった整理がしにくいです。共通のベースラインとして、Meta コア DNS リーク防止ガイド で推奨される解決経路の一元化を先に満たし、そのうえでボイスを再確認する流れがおすすめです。
段階的チェックリスト（おすすめの順）
- クライアントとコアのエラー：YAML の読み込み失敗、TUN デバイスの権限、競合 VPN の有無を確認する。
- モード：まずはルールモードと、TUN／システムプロキシのいずれか一方で再現性を比較する。
- ログで UDP：ボイス接続中のエントリに UDP が含まれるか、紐づくポリシー名は何かをメモする。
- ルール命中：
MATCH手前で別ルールに吸われていないか、discord 関連を上段へ移して再テストする。 - DNS：FakeIP／DoH 設定がルール評価と矛盾していないか、ガイドに沿って揃える。
- ノード：同一ルールでも UDP が不安定なら、別ノード・単跳に切り替えて比較する（relay の場合は relay 記事 の UDP 節を参照）。
注意：利用規約や職場・学校の方針によっては Discord やプロキシ利用そのものが制限される場合があります。許可された環境と法的枠組みの範囲内でのみ設定してください。
他記事との棲み分け
ゲーム機向け LAN 共有や mixed-port は題材が異なりますが、UDP がどのポートで LAN に露出するかは LAN 共有記事 に整理があります。HTTP/3（QUIC） がブラウザだけ別経路になる話は、UDP 全般の切り分けで意識すると重なります。本稿はあくまで Discord の音声が Clash 配下で不安定に感じるという問いに絞り、TUN と UDP とルールの三位一体で読者が自分のログに落とし込めることを目標にしています。
まとめ
Discord の 音声通話が Clash Meta／Mihomo 環境で不安定に感じるときは、テキストと同じノード・同じルール語彙で説明がつかないかを最初に疑うより、UDP がどのポリシーに載っているかとTUN かシステムプロキシかによる捕捉差を事実ベースで確認するほうが早いことが多いです。ルール順の調整、discord 関連ホストの明示、DNS と FakeIP／DoH の整合の三段を整えれば、「文字は見えるが声だけ途切れる」系の症状はかなり減じやすくなります。クライアントの導入や更新は、仕様確認とあわせて当サイトの 公式ダウンロードページ から行うと、配布物の取得目的が不明瞭になりにくくなります。用語とモードの対応は ドキュメント・チュートリアル も参照してください。
同種のプロキシツールの中でも、Clash エコシステムはルールとログを同じ画面で追いやすいという長所があります。UDP のような見えにくいレイヤでも、一段ずつ切り分ければ体感はかなりマシになるはずです。