ストリーミング換区やDiscord音声の記事と何が違いますか？

いずれもUDPと出口IPの問題を扱いますが、本稿はZoom／Microsoft Teamsの企業会議という文脈に絞り、会議クライアント特有のドメイン階層と、職場ポリシー前提の切り分け順を説明しています。

Zoom・Teamsがカクつく無音？ClashでRTC・UDP・TURN分流 2026

Q: ZoomやTeamsの会議トラフィックはTCPだけですか？

サインインや会議の制御・Webクライアントの多くはHTTPS（TCP）ですが、音声・映像のメディアはUDPとWebRTC（RTC）が主役になり、必要に応じてSTUN／TURNも使われます。そのためHTTPSだけプロキシに乗っていても、UDPが別経路や制限で劣化するパターンが起きやすいです。

Q: システムプロキシだけでは会議が不安定になりますか？

HTTP(S)は取り込めてもUDPが同じ経路に乗らない、あるいはClash側のUDPリレーと相性が悪い場合があります。症状がメディアに偏るときはTUNモードの有無や、ノードがUDPを十分扱えるかを疑うのが一般的です。

Q: STUNとTURNはルールでどう扱えばよいですか？

ホスト名は製品・テナント・リージョンで変わるため、固定的な一覧一本に頼らず、クライアントのログや接続情報で実際に出た宛先を確認し、DOMAIN／DOMAIN-SUFFIXで希望のポリシーグループへ束ねるのが安全です。企業ネットワークでは管理者が開放する範囲と必ず整合させてください。

ステップ1：症状を「HTTPSの制御」と「UDP／RTCのメディア」に分ける

最初に現象を言語化します。サインイン・会議への参加リンク・チャット・ファイルプレビューまでが比較的安定していて、問題が通話開始後の映像・音声・画面共有に集中する場合、疑うべきは「ブラウザやデスクトップクライアントが送る HTTPS リクエスト はプロキシ経路に載っている一方で、UDP で流れるメディア が別ポリシー・別品質になっている」というパターンです。Zoom と Teams はともにクラウド側の構成やクライアントのバージョンで接続先ホストが増減するため、公開されているドメイン一覧をそのまま丸写しするより、自分の環境のログに出ているFQDN を一次情報にすることが安全です。

切り分けの観点は次のとおりです。第一に、システムプロキシ のみを有効にしている場合、アプリによっては HTTP(S) は確実に取り込めても UDP を同じ出口に載せられない ことがあります。第二に、TUN を使うと取り込み方が変わり、UDP も含めてルールに乗りやすくなる一方、仮想アダプタや他VPNとの競合の影響を受けやすくなります。第三に、通話が RTP／SRTP や WebRTC ベースだと、TCP 主体のウェブ閲覧より ジッター（遅延の揺らぎ） や パケット損失 に敏感です。第四に、ノードの種類によって UDP リレー の扱いがまちまちなので、同じ「ルール代理」でもメディアだけ破綻することがあります。

この段階で Clash のログ（ルールヒット・接続ログ）を開き、会議中に どのホストがどのポリシーグループにマッチしたか をメモします。以降の YAML 追記はこのメモが土台になります。システムプロキシと TUN の整理は Clash TUN とシステムプロキシの比較・トラブルシュートで補足できます。

「グローバル PROXY なのに直らない」とき 画面表示上はすべて代理に見えても、DNS・ループバック・企業証明書プロキシ・セキュリティ製品のドライバ層で経路が割れていることがあります。ログの一行を手掛かりに、HTTPS と UDP を分けて見ることが近道です。

ステップ2：Zoom／Teams の会議ドメインをログで束ね、専用ポリシーグループへ送る

検索クエリになりやすい zoom.us や teams.microsoft.com は出発点として有効ですが、実際のクライアントは *.zoom.us、CDN 名、認可エンドポイント、Teams なら microsoft.com 配下の複数サービスに分散します。ルール分流 では、まず購読の Rule Providers に任せつつ、自分のログで確定した接続先 を DOMAIN または DOMAIN-SUFFIX で束ね、会議に使いたい出口 をまとめたポリシーグループ（例：MEETING-EXIT）へ送るのが現実的です。

設計のコツは、最初からドメインを過剰に細切れにしないことです。「会議アプリ関連を一つの select／url-test に載せる」 で足りるケースが多く、細分化するなら 認証・CDN・メディア のように役割が明確に違う塊だけ分けると YAML の保守が楽です。分流の骨格は Clash YAML ルール分流ガイドで扱っているので、本稿では会議シナリオ向けの 追記位置 と 購読ルールとの競合 に焦点を当てます。

proxy-groups:
  - name: "MEETING-EXIT"
    type: select
    proxies:
      - "node-low-latency"
      - "PROXY"
      - "DIRECT"

rules:
  # Place meeting rules ABOVE broad GEOIP / MATCH
  - DOMAIN-SUFFIX,zoom.us,MEETING-EXIT
  - DOMAIN-SUFFIX,teams.microsoft.com,MEETING-EXIT
  # Add hostnames from your client logs (Zoom/Teams releases change FQDNs)

上の例は たたき台 です。RULE-SET が先にマッチ しているとカスタム行を足しても効かないので、競合する行より上に移す か、購読側の順序設計を見直してください。また、会議機能が ブラウザ（Edge／Chrome） 経由か デスクトップ専用クライアント かによって出るホストが変わる点にも注意します。

ステップ3：STUN／TURN・UDP メディアが意図した経路に乗っているか確認する

WebRTC（RTC） は peer 間の接続確立に STUN を使い、ファイアウォール越えが難しいときに TURN サーバを中継として使うことがあります。ここが途切れると「相手の声は届くが自分の声だけ出ない」「映像だけ一方通行」など、典型的な片方向トラブルに見えます。TURN のホスト名やIP帯はテナント設定や地域で変わるため、静的なリスト一冊だけに依存せず、クライアントの統計／接続テスト画面 と Clash のログ を突き合わせるスタイルが安定します。

UDP まわりでは、利用中の Clash Meta（mihomo）コア とクライアント GUI の組み合わせが、UDP を期待どおり扱えるかが焦点になります。節々で挙動差が出るため、必要ならコアのアップグレードも検討対象です。ノードについては、同じサブスクリプション内で レイテンシの低い別ノード に切り替えて会議の安定性が変わるか試し、変わるならプロトコルや事業者側の UDP 経路がボトルネックの可能性があります。あわせて OS の ファイアウォール やエンドポイントセキュリティが、Clash のプロセスや仮想 NIC 宛の UDP を制限していないかも確認します。

職場・学校のポリシーを最優先に 会議システムの設定変更、トンネルの利用、許可されていないプロキシ経路の使用は、所属先の規約やセキュリティ方針に抵触する場合があります。本稿は正当な権限と方針の範囲でネットワークを整理するための技術メモです。

ステップ4：TUN と「アプリ全体の取り込み」——システムプロキシだけでは足りないケース

会議クライアントが システムプロキシ設定を参照しない 実装である、あるいは内部でプロキシをバイパスする挙動があると、HTTPS だけ偶然通っていて UDP が直結側に逃げる、といったミスマッチが起きます。TUN はトラフィックの取り込み方を変えるため、こうしたケースの解になりやすいですが、管理者権限や仮想アダプタの競合、他の VPN との二重トンネルなど、環境固有の要件も伴います。

実務では、まず「会議アプリを起動した状態で Clash のログに UDP が現れるか」を確認し、現れない場合は TUN の有無やクライアントのプロキシ設定を変えて再測定します。また、Split tunnel 系の設定を OS 側で持っている場合、会議アプリだけが別インタフェースに抜ける こともあるため、Wi‑Fi と有線の切り替えや VPN のオンオフでも再現性を見ると切り分けが早くなります。

ステップ5：DNS（Fake-IP）とルール順——MATCH より上に会議用の行を置く

ルールは 上から最初の一致だけ が有効です。購読プロファイルの末尾が MATCH や広い GEOIP になっているとき、会議向けの行が下に沈んでいる と意図したポリシーに届きません。Fake-IP を使っている場合は、名前解決の見え方が変わり、ルールマッチのタイミングが直感とずれることがあります。DNS の整理は Clash Fake-IP と Redir-Host の比較・ローカル解決トラブルと併読するとよいでしょう。

コツは次の三つです。第一に、会議関連の DOMAIN 行を GEOIP／MATCH より上に移す。第二に、nameserver-policy などで特定ドメインの DNS を分けている場合、解決結果とルールの組み合わせが想定と揃っているかログで確認する。第三に、購読を更新した直後だけ症状が変わるなら、追記した行が RULE-SET に負けている 可能性を疑う。これらはいずれも「YAML に一行足したつもり」でも、順序と DNS で無効化されうる典型パターンです。

補足：Netflix 換区・Discord 音声の記事との違い

Netflix の regional 視聴向け記事はストリーミング CDN とエグジット地域の整合を中心に据えています。Discord の音声向け記事は discord.gg とボイス UDP を同じ棚で扱う構成です。一方、本稿の Zoom／Teams は、多くの場合 職場アカウントとセキュリティポリシー が絡み、利用可能なプロトコルや必要な開放ポートが組織ごとに異なります。「同じ UDP 問題」でも 個人の娯楽ストリーミング と 企業会議 では前提が違う、と頭の片隅に置いてください。

よくある質問（補足）

ZoomやTeamsの会議トラフィックはTCPだけですか？

制御やWeb部分はHTTPS（TCP）ですが、音声・映像のメディアはUDPとWebRTCが主役で、STUN／TURNも使われます。

システムプロキシだけでは会議が不安定になりますか？

HTTP(S)は通ってもUDPが同じ経路に乗らない、またはUDPリレーと相性が悪い場合があります。TUNの有無やノードを疑います。

STUNとTURNはルールでどう扱えばよいですか？

ホストは可変なのでログで実測し、DOMAINで希望のポリシーに束ねます。組織の許可範囲と合わせてください。

まとめ

2026 年時点でも、Clash 利用中に Zoom／Microsoft Teams の会議だけがカクつく・無音になる悩みは、TCP と UDP／RTC の役割分担 を理解すると説明しやすくなります。対処の中心は、会議クライアントが実際に触れているFQDN をログで確定し、ルール分流 で望む出口の ポリシーグループ に束ねること、そして UDP・TURN が意図した経路に乗っているかを TUN やコアの組み合わせで裏取りすることです。DNS と RULE の順序 を軽視すると、YAML を足したつもりが効かないまま時間を溶かしがちなので、まず MATCH より上 と Fake-IP の見え方 を確認する流れがおすすめです。

クライアントの入手や各 OS 向けの一覧はダウンロードページからまとめて確認できます。購読リンク（サブスクリプション URL）の更新や、追記した YAML の反映は、利用中の GUI の手順に従ってください。

→ Clashを無料ダウンロード — Meta コア対応の各クライアントを比較し、会議時の UDP／TUN まわりも含めて試せます。

関連：YAML ルール分流の全般、TUN とシステムプロキシ、技術コラム一覧。