ステップ1：症状を「TCPのDiscord」と「UDPの音声」に分けて理解する
まず現象を言語化します。サーバーへの参加・メッセージの送受信・絵文字の同期 などが比較的安定していて、問題が ボイスチャンネル接続後 に集中する場合、疑うべきは「HTTPS だけがきれいにプロキシへ流れ、UDP のメディアストリーム が別経路・別品質になっている」パターンです。Discord クライアントはバージョンや地域によって接続先ホストが変わるため、教科書どおりの固定リストよりも、自分の環境で実際に出ているホスト名 を一次情報にすることが重要です。
確認の観点は次のとおりです。第一に、システムプロキシ だけを有効にしている場合、ブラウザや一部アプリは HTTP(S) を確実に取り込めても、UDP を同じ経路に載せられない ことがあります。第二に、TUN モード を使うとトラフィックの取り込み方が変わり、UDP も含めてポリシーに載りやすくなりますが、その分 除外設定 や 競合する VPN の影響も受けやすくなります。第三に、ノード側が UDP に弱い、もしくは レイテンシが不安定 だと、TCP の小さなリクエストは通っても音声の連続ストリームでは破綻が目立ちます。
ここまでを踏まえたうえで、クライアントのログ（接続ログ・ルールヒット・エラー）を開き、Discord 関連のホストがどのポリシーにマッチしたか をメモしておきます。次のステップでドメインを YAML に落とし込むときの土台になります。TUN とシステムプロキシの違いの整理は Clash TUN とシステムプロキシの比較・トラブルシュート が参考になります。
ステップ2：discord.gg・discord.com 系をログで特定し、専用ポリシーグループへ
検索意図として多い discord.gg は、招待リンクやリダイレクトでよく見かけるホストですが、通話の本体が常にこの名前だけに集約されるわけではありません。実運用では discord.com、discordapp.com、discord.media など、クライアントが更新とともに触れるホストが増減します。ルールを書くときは、まず購読ルール（Rule Providers）に任せつつ、自分のログで確定したホスト を DOMAIN または DOMAIN-SUFFIX で束ね、安定した出口にしたいポリシーグループ（例：DISCORD-EXIT）へ送るのが現実的です。
ポリシーグループの設計は、過剰に細かくしすぎると YAML のメンテが大変になるため、最初は 「Discord まわりをまとめて一つの select／url-test に載せる」 程度で十分なことが多いです。細かく分けたい場合は、API／CDN／メディア のように責務が違う塊だけ別グループにする、という段階的アプローチがおすすめです。分流の骨格（proxy-groups とルールの並び）自体は Clash YAML ルール分流ガイド で扱っているので、本稿では Discord 向けの 追記位置 と 優先順位 に焦点を当てます。
proxy-groups: - name: "DISCORD-EXIT" type: select proxies: - "node-low-latency" - "PROXY" - "DIRECT" rules: # Place Discord rules ABOVE broad GEOIP / MATCH - DOMAIN-SUFFIX,discord.com,DISCORD-EXIT - DOMAIN-SUFFIX,discord.gg,DISCORD-EXIT # Add hostnames you see in logs, e.g. discordapp.com, discord.media, ...
上の例は たたき台 です。実際の購読プロファイルでは、RULE-SET が先にマッチしてしまう と追記を足しても効かないことがあるため、競合する行より上に移す か、購読側の順序設計を見直してください。discord.gg だけを切り出しても、メディアが別名で出ていれば症状は残ります。
ステップ3：UDP リレー・TUN・クライアント設定で音声パケットを通す
ルールでホストを正しく送れても、UDP がノードまで届かない と音声は途切れます。チェック項目は次のとおりです。第一に、利用中の Clash クライアント が、使用しているコアで UDP を期待どおり扱えるか。古い組み合わせでは挙動差が出るため、必要なら Clash Meta（mihomo）コアのアップグレード も視野に入れます。第二に、TUN モード を使うかどうか。システムプロキシだけでは UDP が取り込めないケースでは、TUN が有効な解になりますが、管理者権限や仮想 NIC の競合など、環境固有の要件があります。
第三に、ノードの種類 です。一部のプロトコルは TCP ベースのトンネルが主で、UDP パケットの扱いが期待とずれることがあります。ボイスが不安定なときは、同じサブスクリプション内で 別のノード に切り替え、改善するかを試す価値があります。第四に、OS 側の ファイアウォール やセキュリティ製品が、仮想アダプタや Clash の実行ファイルに対して UDP を制限していないか。ここはプロキシの設定以前のレイヤですが、見落としがちです。
ステップ4：DNS（Fake-IP）とルール順序——MATCH より上に Discord 行を置く
ルールは 上から順に最初の一致だけ が有効です。購読プロファイルの末尾が MATCH や広い GEOIP になっているとき、Discord 向けの行がその下に沈んでいる と、意図したポリシーに届きません。また Fake-IP モードでは、名前解決の見え方が変わり、ルールマッチのタイミングが TCP のときと異なるように感じることがあります。DNS 周りの整理は Clash Fake-IP と Redir-Host の比較・ローカル解決トラブル と併読すると、症状の切り分けが早くなります。
実務のコツは次のとおりです。Discord 関連の行を GEOIP や MATCH より上に移す。nameserver-policy などで特定ドメインの DNS を分けている場合、解決結果とルールの組み合わせが想定とずれていないかログで確認する。購読ルールを更新 した直後にだけ症状が変わる場合は、追記したカスタム行が 購読側のルールセットに負けている 可能性を疑う。これらはいずれも「YAML の一行を足したつもり」でも、順序と DNS で無効化されうる典型パターンです。
ステップ5：ノード品質・地域表示・再接続で最終確認する
技術的な経路が揃っても、ノードの混雑・ルーティング・ピーク帯の輻輳 で音声が劣化することは珍しくありません。Discord 側の リージョン表示 が期待と違う場合、出口 IP の所在地とノードの実体が一致しているか、別タブで確認すると腹落ちしやすいです。また アプリの再起動、ボイスチャンネルの退室／再入室、ルーターの再起動 など、単純なリセットで回復するケースもあります。ここまで試しても改善が限定的なら、同じ条件で別のクライアント GUI を試し、再現性があるかを見るのも有効です。
ゲーム機やストアの CDN 分流で使った 任天堂ネットワーク分流 や Steam／Epic 分流 と同様、「ドメインを束ねる」より前に、どのプロトコルがボトルネックか を決めるのが本テーマでも効きます。Discord は UDP／RTC が前面に出る点が決定的に違います。
よくある質問（補足）
Discordの音声はTCPではなくUDP中心ですか？
通話のメディア部分は UDP（WebRTC）を使うことが多く、チャットや画面の一部の制御は TCP（HTTPS）側に寄ります。だから「HTTPS はプロキシで通るのに音声だけ不安定」というパターンが起きやすいです。
ClashでUDPは通りますか？
クライアントとコアの組み合わせ、TUN の有無、ノードプロトコルによって見え方が変わります。ログで UDP が意図したポリシーに載っているかを確認してください。
discord.ggだけプロキシに載せれば足りますか？
招待リンク用のホスト名だけでは足りないことが多いです。実際の接続先をログで確認し、必要な DOMAIN をまとめて同じグループへ寄せてください。
まとめ
2026 年時点でも、Clash で Discord を使うときのつまずきは、「文字は通るが 音声 だけが悪い」に集約されやすいです。対処の中心は、discord.gg や discord.com 系を ルール分流 で意図した出口に載せることに加え、UDP／RTC が TUN やコアの組み合わせで実際に通っているかをログで裏取りすることです。DNS と ルールの順序 を軽視すると、YAML を足したつもりが効かないまま時間を溶かしがちなので、まず MATCH より上 と Fake-IP の見え方 を確認する流れがおすすめです。
クライアントの入手や各 OS 向けの一覧は ダウンロードページ からまとめて確認できます。サブスクリプション URL の更新や、ルールを追記した YAML の反映は、利用中の GUI の手順に従ってください。無料で試せるクライアントから順に、自分の環境で UDP が安定する組み合わせを探すのが現実的です。