Discord ボイスとゲーム UDP：Clash TUN・中継ノード・プロセスルールで遅延を順に直す

症状と検索意図：何が「UDP っぽい」のか

ブラウザのページ表示が速くても、ボイスチャンネルだけ途切れる、ゲーム内の位置同期だけ遅れる、といった差はトランスポートが UDP 中心であることが多いです。TCP の再送や順序保証が効きにくい分、経路上のジッターやキュー滞留がそのまま体感遅延になります。また、同じ「プロキシ有効」の表示でも、システムプロキシだけの環境ではゲーム実行ファイルがプロキシを読まず、TUN を入れた瞬間に初めて UDP が出口に乗る——という切り替わりが起きます。だから「昨日まで普通だったのに今日からボイスだけおかしい」は、設定変更とセットで見る価値があります。

ユーザーの検索意図は大きく二つに分かれます。① ブラウザやチャットだけ海外出口に出したいが、ボイスと対戦は自宅回線のままがいい。② どうしてもボイスもプロキシ経由にしたいので、UDP に強いノードやトポロジーを選びたい。① はルールで DIRECT に戻す設計、② はノード種別・中継段数・地域の近さを詰める設計になります。まず自分がどちらに近いか決めると、手戻りが減ります。

• 片道無音：片側の RTP が別経路・別 NAT 挙動になっている、または片側だけ高損失ノードに載っている。
• 遅延だけ悪化：往復が伸びているのか、下りだけ詰まっているのかをログと MTR で分ける。
• 切断：キープアライブが届かない、またはセッションが途中で別ポリシーに切り替わった。

Clash TUN と UDP：捕捉範囲を理解する

TUN は仮想インターフェース越しにOS が送出しようとしたパケットを Clash が受け取ります。環境によっては「UDP も含めて既定ゲートウェイ側に流れるもの」が対象になります。だからこそ、Discord デスクトップやゲーム本体が想定外にプロキシグループへ載った瞬間に、UDP の RTT が跳ねることがあります。逆に言えば、TUN が有効でもルールで DIRECT に落とせば、そのフローは自宅 ISP の経路に戻ります。

Clash Meta 系では、コアのバージョンと設定項目によって UDP の扱いやスニッファの影響が変わります。ここでは「まずはログでどのプロセスがどのポリシーに載ったか」を確定させることを最優先にします。体感よりログが先です。

PROCESS-NAME / PROCESS-PATH で「ブラウザ」と「ボイス」を分ける

Windows では Discord.exe がボイスと UI の両方を担う一方、ブラウザ版 Discord を使うならブラウザのプロセス名が別になります。「ブラウザだけプロキシ」にしたい場合、Chrome や Edge の実行ファイル名をプロキシ側に寄せ、Discord.exe を DIRECT にする、という分け方が素直です。ゲームも同様で、対戦用の SomeGame.exe を先に DIRECT で固定し、ランチャーやアップデータだけ別グループへ——Steam / Epic の記事と組み合わせると運用がブレにくくなります。

プロセス行は粗い GEOIP や最終 MATCH より上に置きます。順序が逆だと、UDP も含めて広いルールに先に吸われ、意図した DIRECT が効かないままになります。同名 exe が複数ある場合は PROCESS-PATH でフルパスを絞り込みます。

# Illustrative rules — verify process names on your OS
rules:
  - PROCESS-NAME,chrome.exe,PROXY
  - PROCESS-NAME,Discord.exe,DIRECT
  - PROCESS-NAME,SomeGame.exe,DIRECT
  - MATCH,PROXY

ノードプロトコルと中継（relay）：UDP に効く「形」

同じ「海外サーバ」でも、TCP 主体のブリッジと、UDP を素直に運ぶトンネルでは体感が変わります。現場では「VMess より VLESS / Hysteria / TUIC などUDP に設計寄りのスタックが安定しやすい」という印象を持つ人が多い一方、契約先の実装差が大きいので絶対視は禁物です。重要なのは、自分の購読で UDP が想定どおり通るかを小さなテスト（短時間の通話・カスタムゲームルーム）で確かめることです。

中継（relay）は、クライアントから中継サーバ、そこから出口ノードへとホップが増える典型パターンです。レイテンシは伸びやすいですが、片側だけ到達不能なトポロジーを回避できるケースもあります。片道無音が「特定の友達との組み合わせだけ」で起きるときは、相手側の NAT や地域と、自分側の出口都市の組み合わせを変えて試す価値があります。

観点	直結（DIRECT）寄り	プロキシ寄り
RTT	一般に最小。対戦・ボイス最優先なら第一候補。	出口や中継が増えるほど伸びやすい。ジッターも増えやすい。
到達性	ISP とピアの経路次第。キャリアグレード NAT などは別問題。	ブロック回避には強いが、UDP 劣化のリスクとトレード。
運用	プロセスとドメインのメンテが必要。	ノード切替で一括変更しやすい。

ドメインルールは「補助」として使う

Discord はドメインが複数に分散し、クライアント更新で変わり得ます。だからドメインだけでボイスを完全制御しようとすると運用コストが跳ね上がりがちです。現実的には、PROCESS-NAME で大枠を決め、ログに出た特定のホストだけをピンポイントで別ポリシーにする、という二段構えが扱いやすいです。広すぎる DOMAIN-SUFFIX は、意図せず別アプリの TLS まで巻き込みます。

ゲームタイトルによっては、マッチメイキングとボイスが別ポート・別プロトコルです。ストア系記事で触れた「ランチャーと本体の二分」と同じ発想で、ログのプロセス列と宛先ポートをセットで見てください。

DNS・fake-ip：無音の「見かけ」と実経路

fake-ip モードでは、アプリケーションが見ている名前解決結果と、カーネルが実際に向ける宛先の関係が分かりにくくなります。ボイスやゲームが「接続は張れたのにすぐ切れる」場合、DNS の帰りと実フローの不一致を疑います。詳細は DNS と fake-ip の記事で扱っているので、変数は一つずつ変えてください。TUN を足した直後だけ壊れるなら、まず DNS モードと nameserver の順序を見直すのが安全です。

Windows / macOS の土台

Windows で TUN の前提がまだなら Clash for Windows の完全設定から。macOS はネットワーク拡張の権限が絡むため、Clash Verge Rev の初回設定を先に完了させてから UDP の切り分けに入ると早いです。どちらの OS でも、他社 VPN やフィルタドライバが同時に有効だと二重捕捉になり、UDP だけ奇妙な挙動になることがあります。

よくある質問

片道だけ声が聞こえない

自分の送信経路と相手の受信経路のどちらかに非対称が出ていないか、別ノード・別都市で短時間テストしてください。プロセスが DIRECT に落ちているかもログで確認します。

ブラウザだけプロキシにしたい

ブラウザプロセスを PROXY、Discord.exe とゲーム exe を DIRECT。TUN を使うなら「捕捉はするがルールで戻す」イメージです。システムプロキシのみに戻す選択肢も比較対象に入れます。

中継にしたら遅延が悪化した

典型的にはホップ増です。到達性の問題が解決しないなら中継の意味が薄いので、単一跳の別ノードや、ボイスだけ DIRECT に戻す案を比較してください。

チェックリスト

まとめ

Discord ボイスとゲーム UDP は、「プロキシに乗せる／乗せない」の判断がブラウザよりシビアです。Clash TUN は強力な捕獲手段ですが、その分ルール順とノード特性の設計ミスがそのまま無音や切断に現れます。まずプロセスで戻せるかを確かめ、必要なら UDP 向きのプロトコルと中継トポロジーを段階的に詰めてください。

Clash を無料ダウンロードして、快適な接続を体験する