1. 症状の読み解き：更新 0% と通話切断は「別レイヤーの失敗」になりやすい
アップデートが進まない問題と、ボイスが不安定な問題は、原因が完全に一致するとは限りません。前者はHTTPS での大容量取得や差分パッケージの署名確認に失敗しているケース、後者は低遅延を要するメディア経路やUDP を含むセッションが別ルートに落ちているケースが重なります。ただし共通しているのは、Discord が起動直後から複数ホストへ並列アクセスする点です。Clash の接続一覧に出るホスト名と実際に選ばれた策略を時系列で並べると、「更新だけ DIRECT で詰まり、本体 API はプロキシで通っている」といった部分的成功が想像以上に早く見えてきます。
YAML の骨格やルールモードをまだ把握していない場合は、先にサブスクリプション取り込みの記事で設定ファイルの流れを押さえておくと、以降の手順が読みやすくなります。
2. Discord 周辺通信を「層」に分けて考える
以下は設計メモとしての区分であり、実際のサブドメインは環境で変わります。重要なのは、一枚岩のドメイン想定でルールを書かないことです。
| 層 | イメージ | 切り分けのポイント |
|---|---|---|
| アプリ本体・認証 | discord.com、discord.gg 系 | ログインやサーバー一覧は通るのに更新だけ止まるときは CDN 側を疑う。 |
| 静的 CDN・配信物 | discordapp.net や CDN サブドメイン | 大容量取得が別経路だと 0% のまま時間が溶ける。 |
| ゲートウェイ・シグナリング | gateway 系ホスト名 | テキストは動くがボイスだけ不安定なときにログを確認。 |
| メディア／RTC | 地域コードを含むメディア系、UDP セッション | 遅延の揺れやプロキシの UDP 透過性が効く。TUN と併用時の競合も要確認。 |
2026 年時点でもクライアントは頻繁に更新されるため、過去に動いていたルールが突然効かなくなることは珍しくありません。購読ルールに頼り切らず、自分のログで一度表を作り直すのが安全です。
3. Windows 特有の経路：Electron アプリとシステムプロキシの取りこぼし
Discord デスクトップは Electron 系の典型で、OS のシステムプロキシ設定を参照しますが、他 VPN や企業プロファイルと併用すると見かけ上だけ別ルートに落ちることがあります。まず Clash 側でシステムプロキシかTUNのどちらでトラフィックを握っているかを確認し、接続ログで Discord 相当の行が期待する策略グループに入っているかを見ます。Microsoft Store 系だけ別問題になることもあるため、Windows でのプロキシ挙動の理解にはUWP のループバックと Clash の記事も参考になります。
4. ドメイン収集：更新再現と通話再現を分けてログを取る
収集の基本は次の流れです。更新とボイスは別シナリオとして切り出すと読みやすくなります。
- Clash を起動し、システムプロキシまたは TUN を有効化する。併用中の別 VPN は一旦切る。
- Discord を起動し、アップデートが 0% のまま止まる状態を再現する。接続ビューで同時刻付近のホストをメモする。
- 別セッションで、ボイスチャンネルに入室し、途切れや切断を再現する。UDP を含む行が見えるクライアントなら、その策略名も記録する。
DIRECTや想定外のポリシーに落ちている行に印をつけ、購読ルールのどの行より上に自作ルールを置くべきかを検討する。
ポート占有やコア起動失敗など汎用トラブルはトラブルシュート記事へ。本稿は Discord 特有のマルチドメイン構成と RTC まわりに焦点を当てます。
5. 推奨する切り分け順序
- Clash が起動していること、システムプロキシかTUNのどちらでトラフィックを握っているかを確認する。
- 接続ログで Discord 関連ホストが意図したポリシーグループに入っているか、誤った
DIRECTがないかを見る。 fake-ipを含む DNS 設定を確認し、必要なら特定サフィックスへnameserver-policy等を当てて名前解決のブレを減らす。- 本体・CDN・ゲートウェイ／メディアをホスト／サフィックス単位でルール化し、購読ルール内の広い
DIRECTより上側に矛盾なく配置する。 - 更新とボイスを別々に検証し、必要なら別ポリシーグループ（例：安定重視ノードと帯域重視ノード）へ振り分ける。
6. システムプロキシと TUN：取りこぼしを減らす
システムプロキシは手軽ですが、プロキシ設定を読まないコンポーネントや、別ドライバの VPN と併用すると見かけ上の経路が分裂します。TUN はルーティング層で取り込むため一貫性は上がりますが、他 VPN との競合や権限まわりのトレードオフがあります。有効化するならTUN モードの解説を参照し、有効化後に再接続ログで Discord 関連ホストがすべて期待どおりの経路になったか検証してください。UDP を扱うクライアントでは、TUN 側の挙動とノード側の UDP 透過性をセットで見るのが実務的です。
7. DNS／fake-ip：名前解決とルール判定のズレ
fake-ip は体感速度を上げる一方、設定次第では「ルールに渡る前の名前」と「実接続の宛先」の整合が崩れやすくなります。Discord のようにサブドメインと CDN が多いサービスでは、軽いズレでもクライアントがリトライを繰り返し、ユーザーにはただのローディングや通話の途切れに見えます。対策の基本は、上流 DNS を信頼できるものにそろえ、ログで頻出する主要サフィックスへ専用の名前解決ポリシーを当てることです。フィールド名はコアのバージョンで差があるため、利用中の Mihomo／Clash Meta のドキュメントと照合してください。
8. 分流ルールの考え方（記述例は置き換え前提）
購読ルールに「広い DIRECT」が先に入っていると、意図せず国内直結へ落ちるホストが紛れ込みます。より具体的な DOMAIN／DOMAIN-SUFFIX を、矛盾なく上側に置くのが実務的です。以下は例示であり、実際のホスト名は必ずログで確認して置き換えてください。CDN のサフィックスを丸ごとプロキシに載せると、Discord 以外のサイトへ副作用が出ます。ログに出た特定サブドメインに絞るか、ルールセットの細分化を検討してください。
# Example only — verify hostnames in your Clash logs before use
rules:
- DOMAIN-SUFFIX,discord.com,PROXY
- DOMAIN-SUFFIX,discord.gg,PROXY
- DOMAIN-SUFFIX,discordapp.net,PROXY
- DOMAIN-SUFFIX,discord.media,PROXY更新取得だけ別グループ（例：PROXY_CDN）に分け、ボイス用（PROXY_VOICE）と切り離すと、障害時の切り分けが容易になります。UDP が不安定なノードをボイスに使わない、といった運用とも相性がよいです。グループ名は proxy-groups に定義済みである必要があります。
9. Steam 向け CDN 分流記事との違い
当サイトの Steam 記事は、ストア UI とダウンロード用ホストのマルチドメインが中心です。本稿は Discord の更新取得とボイス RTC にスコープを絞り、HTTPS の大容量取得と低遅延メディアの両方を扱います。ゲーム配信クライアントとボイスアプリを併用する方は、それぞれ別のホスト表を持つと混乱が減ります。Steam 向けの手順はSteam CDN 分流記事を参照してください。
10. ノード選定：瞬間最速より「揺れの少なさ」と UDP の相性
スピードテストで一位でも、短時間で往復遅延が跳ねるノードは、ボイスのような連続ストリームには不向きです。TLS の再ハンドシェイクが増え、クライアント側はタイムアウトや途切れとして現れます。手動選択で様子を見たり、ボイス専用に安定路線を固定するのが実用的です。UDP を中継する構成では、ノード側の制限やキャリアグレード NAT の影響も出やすいため、別ノードを試す前に経路の一貫性を先に確認する方が再現性が高いです。プロトコル特性の比較はプロトコル比較記事も参考になります。
11. 追加の落とし穴：複数 VPN、QoS、Discord 内プロキシ設定
Clash 以外の常駐 VPN と TUN を同時に有効にしている場合、ルートの奪い合いで「ときどきだけ直結」が紛れ込みます。またルータ側の QoS で UDP が抑えられていると、プロキシ設定が正しくても通話だけ劣化します。Discord クライアント内に独自のプロキシ設定が残っている場合は OS 設定と二重化するため、検証時はオフに戻すのが無難です。別 PC へプロキシを配る場合は、LAN プロキシの記事で allow-lan とファイアウォールの要点を押さえてください。
12. まとめ：証拠ベースで CDN と RTC を束ねる
Discord の更新が 0% のまま進まない症状や、ボイスチャンネルでの途切れは、単一設定ミスよりもモード・DNS・ルール順・ノードの揺れの積み重ねで起きがちです。本稿の順序どおりにログで確認していけば、「とりあえず別ノード」より再現性の高い改善が期待できます。2026 年もリアルタイムコミュニケーションのインフラは変化が早いので、購読ルールに頼り切らず、自分の環境で一度ホスト表を更新する習慣を持つと安心です。
接続ログとルール編集を GUI でまとめられるクライアントを使うと、YAML を毎回手で触る負担も下がります。同種ツールのなかでも、策略表示とコアの整合が取りやすい製品ほど長く運用しやすい印象です。Discord を安定して使いたい方は、→ Clash を無料ダウンロードして、快適な接続体験を始める