症状の整理：「開かない」と「声だけ悪い」は層が違う

検索クエリに現れやすい「Discord が開かない」「ボイスがカクつく」は、一見同じアプリの不調に見えて、ネットワーク的には当たりどころが分かれます。起動画面で止まる・ログインできない・サーバー一覧が更新されないといった症状は、多くの場合 HTTPS（TCP）経由の API や CDN、認証まわりの到達性が関係します。一方、テキストチャットや画面共有は概ね問題ないのに、通話だけ遅延や途切れが出る場合は、UDP を使ったリアルタイム転送や、地域に紐づくメディア／ゲートウェイ経路がボトルネックになっていることがあります。

Clash 利用者が陥りやすいパターンは、「ブラウザ用のシステムプロキシだけ整えたつもり」なのに、デスクトップ版 Discord が別経路を踏んでいる、あるいはUDP 分流が期待どおりプロキシ側に乗らない、というズレです。ここを「アプリのバグ」として片付ける前に、どのホスト名の通信をどの proxy-groups に流しているかと、TUN／システムプロキシのどちらを主にするかをセットで確認すると切り分けが早くなります。

Discord で押さえたいドメインと「ルールだけ」では足りない理由

クライアントや公式ドキュメントの更新で変わり得るため、環境ごとに実測が前提ですが、少なくとも discord.com、discordapp.com、（旧来の記述やリダイレクトで出る）discord.gg、CDN やメディア配信に関わる discordcdn.com／discord.media など、複数のサブドメインにリクエストが分散するのが一般的です。API や認証、静的アセット、ボイス向けのエッジがそれぞれ別ホストに分かれているため、Clash Discord を安定させるには「代表的な_suffix を DOMAIN-SUFFIX で束ねる」か、信頼できる RULE-SET を購読して追従するのが運用しやすいです。

ただしドメイン分流だけを敷いても、UDP が意図した出口に乗らないケースは残ります。HTTP(S) プロキシはもともと TCP を主対象とし、実装やモードによってはアプリケーションの UDP が直接外に抜ける、あるいはブロックされ気味になる、といった振る舞いの差が出ます。つまり Discord のような音声代理を含むリアルタイム用途では、「どのドメインをどのグループへ」に続けて転送レイヤ全体（TUN 有無、iptables／ルート、クライアントのバイパス設定）を揃える必要があります。

Clash における UDP と「補完」の意味

mihomo（Clash Meta）系のコアでは、利用者のノード種別（VMess・VLESS・Trojan 等）やパラメータ次第で UDP の扱いが変わります。多くの場合、サーバ側が UDP を中継できる構成であれば、クライアントから見た「ゲームやボイスの UDP」も同一トンネルに載せられる一方、誤設定や互換性の制約で UDP が期待どおりプロキシを通らないことがあります。利用者コミュニティで言われる「UDP 分流を補完する」は、ルールでドメインを正しく分けたうえで、(1) そのグループに乗るノードが UDP を扱えるか、(2) アプリのパケットが実際にそのグループへ到達しているか、をログで確認する、という二段構えを指すことが多いです。

ノード選びでは、レイテンシの良さだけでなく、通話中のジッター（遅延のばらつき）に強い出口を選ぶと体感が安定しやすいです。url-test 型の自動選択を使う場合も、測定対象 URL と実際の Discord トラフィックの宛先が一致しないと、テストでは速く見えて通話だけ劣化する、という齟齬が起き得ます。

proxy-groups とルールの例（概念スケッチ）

ブラウジング向けの PROXY とは別に、DISCORD のような名前の select グループを用意し、安定したノードだけを候補に入れると運用が簡単です。サブスクリプション付属の巨大ルールより上位に、アプリ固有のドメインを置いておくとヒットしやすくなります。記法の基礎と優先順位は、YAML・ルール分流の解説記事と併読すると頭の中の地図が揃いやすいです。

# Concept only — verify current hostnames; replace RULE-SET with trusted sources.
proxy-groups:
  - name: DISCORD
    type: select
    proxies:
      - node-low-latency
      - node-backup
      - DIRECT

rules:
  - DOMAIN-SUFFIX,discord.com,DISCORD
  - DOMAIN-SUFFIX,discordapp.com,DISCORD
  - DOMAIN-SUFFIX,discord.gg,DISCORD
  - DOMAIN-SUFFIX,discordcdn.com,DISCORD
  - DOMAIN-SUFFIX,discord.media,DISCORD
  # Keep private / LAN rules above broad MATCH ...
  - MATCH,PROXY

TUN とシステムプロキシ：ボイスに効くのはどちらか

システムプロキシは主要なブラウザや一部アプリに効きやすい一方、UDP や特定のトランスポートをすべて拾うとは限りません。一方、TUN モードは OS のトラフィックをより広くカバーしやすく、Discord のようなデスクトップクライアントの UDP をコアのルールに載せやすい、という説明がなされることがあります。逆に TUN は他の VPN／仮想アダプタと競合しやすいので、環境によっては「ボイスだけ悪化」の原因にもなります。Windows で TUN 周りを切り分けるときは、TUN の実践チェックリスト記事を参照すると手順が揃います。

どちらのモードを使うにしても、「Discord の UDP が実際に意図したグループへ流れているか」を確認するのが本体です。体感で「声だけ落ちる」場合は、TCP の API は別ノードに出ているのに UDP だけ直結している、という非対称も起こり得ます。

DNS・Fake-IP と名前解決の一貫性

ルールはドメイン名ベースでヒットするため、名前解決と実接続の宛先が食い違うと、見かけ上马鹿正直に YAML を書いても期待どおりに動きません。Fake-IP を使う構成では fake-ip-filter にDiscord関連を含める／含めないの影響や、nameserver-policy でドメインごとに DNS を分ける設計が議論されます。詳細は Fake-IP／DNS のドキュメントで補完し、自分のクライアント画面と整合するかを確認してください。

Docker や IDE 分流の記事との違い

当ブログでは、Docker レジストリや Cursor IDE のように特定ドメイン束を専用グループへ送る記事を公開しています。骨格は同じく「ホスト単位で出口を分ける」ですが、Discord は (1) UDP を含むリアルタイム音声が前面に出る、(2) クライアント・モバイル・ブラウザ版でトランスポートの癖が異なる、という点が Docker のレイヤ取得や IDE の HTTPS 主体の切り分けと異なります。検証の焦点を「ルールに加え、転送モードと UDP の実経路」へ寄せるとよいでしょう。

切り分けチェックリスト

1. ルールヒット：discord 系ホストが意図した DISCORD（または同等）グループに落ちているかログで確認する。
2. UDP：通話中にノード側・クライアント側の統計やログで UDP が流れているかを見る（実装依存）。
3. モードの一貫性：TUN とシステムプロキシを混ぜて二重に経路がかかっていないか。
4. DNS：Fake-IP と実接続のリージョンがズレていないか。DNS 解説と照合する。
5. 競合ソフト：別 VPN／フィルタが UDP を奪っていないか。

まとめ

Discord の「開かない／ボイスがカクつく」問題を Clash で扱うとき、Clash Discord 向けにドメインを束ねたドメイン分流は出発点として有効です。そのうえでUDP 分流と表現される領域は、ルールを書いたこと自体よりも、音声代理に相当する UDP が選んだノードとモードに実際に乗っているかどうかが鍵になります。TUN とシステムプロキシ、DNS の一貫性まで含めてそろえると、テキストは読めるのに声だけ途切れる、といった症状の再現と改善がやりやすくなります。

GUI で試す場合も、最終的にどの行がヒットしたかを説明できる状態にしておくと、サブスクやルールセット更新後のデバッグに強くなります。安定したクライアントから試したい方は、ダウンロードページで OS に合う配布物を選ぶと手順が短くなります。ソースコードは挙動理解の助けになりますが、実行ファイルの入手はまず配布ページを主な入口にすると、コアと UI の対応関係を追いやすいです。→ 無料で Clash をダウンロードし、Discord 向け分流の検証を始める