Discord の通話が TCP だけの設定では直らないことがある
Discordのチャット画面や友だち一覧の取得は、多くの場合 TCP 上の HTTPSで十分に観測できます。一方、ボイスチャンネルやビデオ通話はWebRTCを通じてUDPでメディアストリームを張る設計が基本です。ファイアウォールの後ろや、プロキシの UDP 扱いが中途半端な環境では、ページは開くのに「接続中のまま」「すぐミュート状態に戻る」といった断続症状が出やすくなります。
さらに NAT をまたぐ経路では、STUN／TURNが介在し、UDP が届かない・別の出口から戻ってくるとセッションが成立しません。Instant Messaging 向けのTelegram 稿がメッセージ同期と DNS に焦点を当てているのに対し、本稿は音声とリアルタイム転送に寄せ、Discord Clash で検索されやすいUDP 分流とプロキシルールの組み立てを説明します。Steam のストア分流稿とは症状の型が異なるため、混同しないように配置しました。
症状の切り分け：ログイン・チャット・ボイスで見える違い
まず手元で観察できる単位に分けます。discord.com が開けずログイン画面すら出ないなら、ドメイン単位のルール不足や DNS の食い違いが疑われます。チャットと画像は動くがボイスだけ途切れるなら、HTTPS はプロキシに乗っている一方でUDP か TURN だけ DIRECT やブロックに落ちているパターンが典型です。ブラウザ版だけ問題ないのにデスクトップアプリだけダメという場合は、OS が システムプロキシを無視するソケットを使っている可能性があり、TUN モードで全身を Clash に集約する方が再現性が高まります。
ボイス断線を雑多な「回線が遅い」へ丸めがちですが、実務では遅延よりもパケットロスと経路の非対称が効きます。別のノードへ切り替えて帯域は出るのに通話だけ落ちるときは、ノード性能以前にUDP が期待どおり同じ出口で往復しているかを疑うのが近道です。型の整理には接続ログの見方の基礎がそのまま活きます。
UDP を拾う前提：TUN と「プロトコル単位の一貫性」
Clash Meta（Mihomo）では、コア設定とクライアントのモード次第で UDP をプロキシ経由でさばけるようになります。とはいえすべてのノードタイプが同等に UDP を扱えるわけではなく、空港のリモート設定に埋め込まれた proxy-groups がデフォルトのままでは、TCP だけ見えてよくて UDP が別出口、という事故が起きます。
ここで押さえるべきは「ブラウザが見ている世界」と「Discord クライアントが開いているソケット」が同じルールセットを通っているかです。TUNを有効にすると、OS が生成するトラフィックの多くが仮想インタフェース側へ流れ、UDP もログに乗りやすくなります。ゲームや Git 向けにも有効な話は共通ですが、Discord の場合は通話確立直後の短いバーストと長時間セッションの両方を見る必要があります。
Discord 向けドメインとルール順：広い DIRECT より先に置く
Discord が使うホスト名はバージョンや地域で増減するため、接続ログに実際に出た FQDN を正にするのが安全です。それでも設計の型としては、discord.com、discordapp.com、discord.gg、discord.media など、公式が案内するドメイン群を一つのポリシーグループへまとめるのが扱いやすいです。ゲームの DNS 稿であるfake-ip と redir-host の比較記事と合わせて読むと、名前解決と経路の食い違いを減らせます。
以下は概念デモです。既存の proxies 名に合わせて置き換え、コメントは英語のみとします。
proxy-groups:
- name: DISCORD-APP
type: select
proxies:
- JP-LOWLOSS
- SG-LOWLAT
- HK-STABLE
- DIRECT
rules:
# Discord app & site — keep ABOVE broad GEOIP CN DIRECT
- DOMAIN-SUFFIX,discord.com,DISCORD-APP
- DOMAIN-SUFFIX,discordapp.com,DISCORD-APP
- DOMAIN-SUFFIX,discord.gg,DISCORD-APP
- DOMAIN-SUFFIX,discord.media,DISCORD-APP
# Optional: add DOMAIN entries seen in connection logs only
# ... GEOIP / MATCH belowDOMAIN-KEYWORD で雑に拾うと無関係なドメインまで巻き込むため、まずはサフィックスを積み上げる方針を推奨します。リモートの Rule Provider が DIRECT を先に返している場合は、ローカルの prepend-rulesで上書きするオーバーライド機構が便利です。国内向けと海外向けの大方針は分流戦略の記事と同じく、細いルールを上、広い GEOIP を下です。
STUN／TURN と音声リージョン：ノードは「近い」より「落ちにくい」
WebRTC が ICE で候補を探す過程では、Discord 側が提示するリージョンのメディアサーバーと、手元のネットワーク制約が噛み合わないとセッションが張れません。そのとき TURN がフォールバックとして働きますが、TURN 自体も UDP／TCP の複数ポートを跨ぐため、単純な HTTP プロキシ設定だけでは足りません。
実務のコツはレイテンシの数値競争より、パケットロスと切断の少ない出口を選ぶことです。Discord の設定でサーバーリージョンを選べる場合は、契約空港が安定している地域のエッジに合わせると、往復経路の非対称が減ります。URL テストで速いノードが常にボイス向け最適とは限らないので、通話専用にもう一つ select グループを分け、ボイス向けだけ手動で低損失ノードに固定できるようにしておくと運用が楽です。
DNS と fake-ip：名前は合っているのに UDP だけズレる理由
fake-ip で名前解決の見え方を変える構成では、アプリごとにキャッシュした IP と実際の迂回経路がずれることがあります。HTTPS の表示が一瞬通っても、WebRTC が別のインタフェース番号から出ようとして失敗する、という見え方になります。対策の方向性は、enhanced-mode、nameserver、fallback の一貫性を整え、問題が出たときにredir-host など別モードへ一時切替えて比較ログを取ることです。
UDP 分流という言葉だけを増やして YAML を複製するより、TUN の有無・IPv6 の直結・セキュリティソフトのパケット検査の三つを先に疑った方が早い場面が多いです。IPv4 だけプロキシに乗りIPv6 だけが別出口でも、統計上は「たまに切れる」に見えます。
ログで見るべき行：プロトコルとルール命中のセット
接続ログに宛先ホスト、ポート、UDP／TCP、マッチしたルール、選ばれたポリシーが並んでいれば、ボイスが落ちた瞬間にどの通信が DIRECT に落ちているかが追えます。HTTPS と並行して、短時間だけ現れる別ホストへの UDPがないかを見ます。命中は合っているのに失敗ログが出る場合は、ノード側の UDP 帯制限やクライアント側の帯域整形を疑います。
社内や学内のネットワークでは、UDP を制限するポリシーそのものが原因のこともあります。その場合は Clash 側が美しくても根本的に許可されないことがあり、別回線や別端末での確認が必要になります。ネットワーク管理者の方針は必ず順守してください。
まとめ：Discord Clash は UDP とルール順をセットで考える
テキストチャットの設定とボイスは別レイヤです。Discord Clash で検索して辿り着く方にとって効くのは、UDP 分流を口だけでなくログ上で確認できる状態にすること、そしてTUN とルール順で経路を一本化することです。プロキシルールはドメインだけでなく、実際に張られているWebRTC と TURN の往復まで視野に入れると、原因が「ノードが悪い」の前に設計の抜けであることに気づきやすくなります。
クライアントの導入と購読の土台がまだなら、当サイトのダウンロードページから入手し、購読 URL のチュートリアルでプロファイルを読み込んでから本稿のルールを足すと手戻りが減ります。リリースの追跡や Issue は各プロジェクトの GitHub で可能ですが、初回インストールのパッケージはサイトから揃えると取り違えにくいです。オープンソースのコアを活かしつつ、同じ要件でもブラウザ向けと音声向けではUDP と TURNにだけ一手間かけると、体感はずいぶん違ってきます。→ Clash を無料ダウンロードして、Discord のボイス経路を手元で確かめる