この記事で扱う症状（アップデート CDN とボイスは別問題になりやすい）

Discord をWindows で使い、Clash／Mihomo（旧 Clash Meta）をルールモードで動かしていると、(1) インストールやアップデートの進捗が 0% のまま進まない、(2) テキストチャットは問題ないのにボイスチャンネルだけがカクつく・途切れる、(3) ある瞬間からだけRTP 系が不安定になる、といった切り分けがよく起きます。原因は単一ドメインではなく、公式サイトや認証まわりの discord.com 束、メディア取得の CDN、リアルタイム通信の gateway.discord.gg、そして音声向けのUDP が、それぞれ別経路・別ノードへ振られているときに顕在化しやすい構造です。

本稿では、当サイトで既に公開している独立クライアント向けの実測記事──例としてEpic Games のランチャーと CDN を束ねるEpic の分流ガイドや、ストアとオンラインUDP を層別に見るSteam のチェックリスト──と同じ「層を混ぜない」順番で、Discord 固有のホスト設計に落とし込みます。サービス規約・利用地域・コンテンツポリシーは公式に従う前提で、名前解決と転送経路の技術層に限定します。

ステップ 0：症状を「CDN」「ゲートウェイ」「ボイス UDP」のどれかに割り当てる

調査を早く終えるコツは、最初に層を決めることです。(A) ランチャーや About のチェックで「ファイルを落としている」段階で止まるならCDN／配布ホスト、(B) サーバー一覧は見えるが接続確立が不安定ならgateway／WebSocket 周辺、(C) 入室後にだけ音声が割れるならRTP／UDP と NAT・ノード側仕様を疑います。同じ「Discord がおかしい」でも層が違えば増やすべき DOMAIN-SUFFIX と、試すべきトグル（TUN の有無・ノード切替・一時 DIRECT）が変わります。

ゲーム用途と同一 PC で併用するときは、先に Steam 側だけ別グループへ寄せているSteam の UDP 記事の順番と、この記事の Discord 順番を混線させないでください。UDP の不安定は「タイトルではなくプロキシの UDP パスそのもの」が原因のことも多く、片方のルールを直したつもりでもう一方がまだ別ノードに残っているケースが典型です。

ステップ 1：DNS・fake-ip・Windows 側の競合を潰す

アップデートが0% で固まる症状のかなりの割合は、名前解決が期待するノード側から切り離され、別リージョンのエッジへ誘導されていることに起因します。dns.enhanced-mode が fake-ip のとき、評価用の名前と実転送の経路が一瞬でもズレると、広い MATCH より手前に細かいルールが無いホストだけ別ポリシーに落ち、「ブラウザでは discord.com が開くがランチャーだけ進まない」が起きます。

• Windows の「指定された DNS の暗号化」：OS と Clash の DoH が二重になっていないか。競合するとクエリだけ別出口になります。
• IPv6：AAAA が返るが片経路だけ不通なとき、再試行が増えて進捗バーが動かないように見えます。
• ルータ・他 VPN：親機の DNS 強制や別トンネルが、Discord プロセスの解決だけ上書きしていないか。

購読の取り込みと矛盾がないかはサブスクリプション URL 追加ガイドとも整合を取れる話題です。ログでホスト名が見えるクライアントでは、「クエリがどの nameserver に行ったか」と「実コネクションのチェーン」を並べて眺めると早いです。

ステップ 2：分流ルールの優先順位──Discord 束をゲートウェイより上に置く

分流の基本はルール分岐の詳解にある通り、評価は上から順です。Discord では discord.com／discord.gg／discordapp.com（互換で残る名前）に加え、画像・添付まわりの discord.media、配布でログに出やすい discordcdn.com、API discord.com/api に相当するホスト束を、独立したプロキシグループ（ここでは 💬 Discord と仮置き）へまとめて寄せます。gateway.discord.gg は接続の土台なので、CDN 行より後に広い GEOIP で別出口へ落ちないよう、必要なら gateway を明示的に同じグループへ載せます。

proxy-groups:
  - name: "💬 Discord"
    type: select
    proxies:
      - "安定ノード"
      - "低遅延ノード"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,discord.com,💬 Discord
  - DOMAIN-SUFFIX,discord.gg,💬 Discord
  - DOMAIN-SUFFIX,discordapp.com,💬 Discord
  - DOMAIN-SUFFIX,discord.media,💬 Discord
  - DOMAIN-SUFFIX,discordcdn.com,💬 Discord
  - DOMAIN-SUFFIX,discordstatus.com,💬 Discord
  - DOMAIN,gateway.discord.gg,💬 Discord

実際のログには地域や CDN 契約により別名が増えます。ルールセットを丸ごと流用すると過マッチや漏れが出やすいので、「Discord を操作した直後だけ増えるホスト」をログから拾って足す運用が安全です。嗅探（Sniffer）や fake-ip を併用している場合はSniffer とストリーミング分流の記事の評価順も重ねて確認してください。

ステップ 3：CDN とアップデートが 0% のときに見るポイント

進捗が動かないときは、ログ上で該当ホストが本当に 💬 Discord に入っているか、広い GEOIP や末尾の MATCH に吸われていないかを最初に確認します。別ノードへ切り替えるより前に、「そのホストが意図したグループへ分流されているか」を見ないと、ノードを替えても再現が続きます。

一部商用ノードは長時間・太い TCP に対して中間で落ちやすく、速度テストは通るのにバイナリ取得だけが伸びないことがあります。ダウンロードだけ一時的に DIRECT で比較し、改善するなら CDN 系がプロキシ経由で不利なケースと切り分けられます。Epic 記事で触れた「ランチャーと CDN の束ね方」と思考は共通ですが、ホスト名はタイトルごとに異なるため、そのままコピーはしないでください。

ステップ 4：ボイス・RTP・UDP と TUN／ノードの限界

テキストや画像が問題なくて音声だけが途切れるときは、TCP の分流が正しくてもUDP が別経路・別 NAT になっているパターンが多いです。Windows でシステムプロキシのみに依存すると、Discord の音声パケットがプロキシスタックの外へ逃げることがあります。TUN を有効にして UDP を含めゲートウェイ直下で取り込めるかを確認してください。

• ノード側：UDP パススルーや帯域制限の記載を確認し、別ノードへの A/B を短時間で試します。
• ファイアウォール：Discord と Clash の実行ファイルがブロックされていないか、セキュリティ製品が UDP を別扱いしていないか。
• 切り分け：音声だけ一時的に DIRECT、または別グループへ──症状が消えるかで UDP 層かどうかを判断します。

ルールを増やしても直らないときは、「プロキシを挟まない経路」との対比が最も時間対効果が高いです。Steam のオンラインUDPで整理した同記事の NAT／プロキシの限界とも読み替えが効きます。

ステップ 5：Windows 特有の取りこぼし（プロキシ無視・複数 NIC）

Windows では、アプリが WinHTTP／WinINET のどちらを読むか、既定ゲートウェイが複数あるか、Hyper-V や WSL の仮想 NIC が優先されているかで、見かけ上だけ経路が食い違うことがあります。Clash ゲートウェイ構成や LAN 共有をしている場合は、Discord が実際にどのインターフェースから外へ出ているかも合わせて確認してください。

詳細な共通設定はサイト内ドキュメントにまとめています：Clash の設定とチュートリアル一覧。

短いチェックリスト

1. 症状が CDN／gateway／UDP のどの層かを一言で書き分けたか。
2. DNS と fake-ip、OS の暗号化 DNS が競合していないか。
3. discord.*／gateway／CDN ログで見えた名前が、意図したプロキシグループより上に並んでいるか。
4. TUN で音声UDPまで取り込めているか（システムプロキシのみでないか）。
5. ゲーム用ルールとノードを混同して切り替えていないか（Steam 等の UDP 記事と順番を分ける）。

まとめ

Discord のアップデート停滞とボイス途切れは、単一の「discord.com をプロキシに送った／送らなかった」では説明できず、CDN・gateway.discord.gg・RTP／UDP のどこかが分流やDNSの前提とズレているときに起きやすいです。Windows ではTUN とルール順を先に揃え、それでも残る不安定をノードや NAT 層で切り分けるのが実務的です。

Clash／Mihomo 系クライアントでは接続ログと YAML を手元で制御できるため、ホスト名を少しずつ足していく運用とも相性がよいです。ビルドの入手やクライアント概要は、GitHub ではなくサイトのダウンロード一覧を第一の入口にしていただくと、設定読みの順番もブレにくくなります。→ Clash クライアントを無料でダウンロードし、Discord の CDN とボイス経路もルールで揃えた接続を試す