📖 チュートリアル ⏱ 約16分で読めます

リモートワークで Zoom／Teams が繋がらない：Clash の分流ルールと DNS 検証手順（2026）

ハイブリッドワークや越境会議は 2026 年も当たり前です。同じ PC で国内向けツールと、Zoom や Microsoft Teams の海外会議を両立させると、Clash を「全体がプロキシ」のままか、ルールが粗いままにすると、会議に入れない・映像がカクつく・音声が途切れるのに、Web ブラウザだけは「一応」開く、といったズレが起きやすくなります。本稿は実務的なリモートワーク・ビデオ会議の文脈から、分流ルールで会議関連ホストを適切なノードへ寄せ、DNS とシステムプロキシ／TUNの選び方をそろえて切り分ける手順を、端末全体のトラフィックを誤った出口にまとめないことを意識して整理します。開発者向けの Cursor／GitHub 分流や生成 AI 向け記事とは題材を分けた、B 向け・日常業務寄りの記事です。

まず切り分け：「アプリの不具合」か「プロキシが経路を歪めている」か

Zoom と Teams は、参加できない、「接続中」のまま、画面共有が落ちる、音声が途切れる、といった症状が似通います。ただしクライアントの再インストールやノードの連打の前に、Clash をオフにした／Direct にしたときだけ会議が直るかどうかを見ると早いです。直るなら、分流ルール・DNS の解決経路・トラフィックの取り方（システムプロキシ／TUN）のどれかが会議トラフィックと噛み合っていない可能性が高く、サービス自体が完全に封じられているとは限りません。

一方で、組織ポリシー（許可クライアントのみ、社内 VPN 必須、ゲストリンク制限など）で止まる場合は、アプリ側に明確なメッセージが出ることが多く、代理の話ではありません。ここではネットワーク側で自分で調整できる範囲に絞り、Clash で Zoom／Microsoft Teams 向けホストを意図したポリシーグループへ流し、DNS の挙動をルールと一致させる考え方を説明します。トンネル型 VPN とルール型プロキシの違いは Clash と VPN の比較記事 も参照してください。

なぜ「全体をプロキシ」にすると会議が壊れやすいか

グローバルに近い動きは、本来は直結や別の出口がよいトラフィックまで同じノードに送り込み、遅延とジッターを増やしやすいです。リアルタイムの映像・音声は RTT と損失に敏感で、遠回りの中継にまとめて流すのは相性が悪いことが多いです。また、出口 IP の地域がアカウントやテナントの想定とずれると、再接続の繰り返しや機能制限につながるケースもあります。

現実的なのはドメイン単位の分流です。国内のよく使うサイト、社内 LAN、オンプレに近い帯域は DIRECT や別グループに分け、会議に関係するホスト名だけを、遅延が安定していると分かったプロキシグループへ。グループの名前とネストの型は proxy-groups のガイド を参照し、rules 側ではYAML に実在するグループ名と綴りを一致させてください。ここがずれると「ルールを足したのに効かない」になりがちです。

システムプロキシ、TUN、会議クライアントがプロキシを読むか

デスクトップでは Zoom や Teams が独立プロセスで動き、OS のプロキシ設定を必ずしもすべての接続に使うとは限りません。ブラウザでは会議に入れるのにネイティブアプリだけ失敗する、といったときは、会議の一部が Clash に乗っていない疑いがあります。比較しやすいのは次の二つです。

  • システムプロキシ：対応アプリの負担は小さめですが、会議クライアントがプロキシを無視する経路を持つとログに現れないまま外に出ることがあります。
  • TUN モード：より下位でトラフィックを取り込み、カバー範囲は広くなりがちです。一方で社内 VPN や別のトンネルと競合しやすく、DNS や fake-ip の設定も絡みやすくなります。仕組みは TUN モードの解説 を参照してください。

実務では、まず接続ログで会議操作時の宛先がコアに現れるかを確認し、足りなければシステムプロキシ側の強化か TUN かを選ぶ流れが安全です。複数の VPN／加速器を同時に重ねないかも確認してください。

Zoom／Teams 関連ホスト：ログを正としてリストを育てる

ビデオ会議が使うホスト名は、CDN や地域スケジューリング、クライアントの更新で変わり得ます。固定の「完全リスト」はすぐに古くなるので、下記はログを見るときの目安です。実際の設定は必ず自分の端末の Clash 接続ログに出たホスト名を正としてください。

  • Zoom 側の例：zoom.us、zoom.com 配下の業務サブドメインに加え、メディア転送まわりの別ホストが出ることがあります。トップページ用だけルールを書いても、実際の会議セッション用のホストが漏れると「ページは開くが会議に入れない」になります。
  • Microsoft Teams／Microsoft 365：teams.microsoft.com、teams.live.com に加え、microsoft.com、office.com、office365.com、sharepoint.com、skype.com など、テナントと機能によってログに並ぶ名前は変わります。Teams はサインインや OneDrive、Outlook などと基盤を共有するため、ログにマイクロソフト系が複数並ぶのは普通です。

方針として、(1) 巨大なサフィックスを一括でプロキシにする前に、ログで必要な範囲を確認する、(2) 新しいホスト名が出たらルールを足す、の繰り返しが現実的です。ルールの書き方と順序は カスタムルールの解説 と併読してください。

DNS、fake-ip、「名前解決の経路が二択」問題

「時々だけ繋がらない」原因の多くは DNS にあります。OS の DNS、ブラウザのセキュア DNS（DoH）、Clash 内蔵の DNS が同時に動くと、ルールがマッチするドメイン名と、実際に解決に使われた情報が食い違うことがあります。fake-ip を使う構成では、no-resolve やルールの並び、DNS ブロックの設定がセットで効いて初めて一貫します。

会議の不調を追うときは、一度に変えるのは一種類（例：DNS だけ、またはルールだけ）にすると原因を切り分けやすいです。特定の回線（例：固定回線だけ、テザリングだけ）でだけ悪化する場合は、UDP やポートの扱いなどプロバイダ側・回線側の要因もあり得ますが、ログの「名前解決失敗」と「接続は張れたが品質が悪い」は別物として見ると整理しやすくなります。

分流ルールの例：プライベート網は先に DIRECT、会議は専用グループへ

以下は構造の例です。PROXY_MEETING は自分の設定にあるポリシーグループ名に置き換え、ドメインはログに基づいて増やしてください。丸ごとコピーして万能設定にするのは避けてください。

# Example only — replace PROXY_MEETING with your proxy-groups name
rules:
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DOMAIN-SUFFIX,zoom.us,PROXY_MEETING
  - DOMAIN-SUFFIX,zoom.com,PROXY_MEETING
  - DOMAIN-SUFFIX,teams.microsoft.com,PROXY_MEETING
  - DOMAIN-SUFFIX,teams.live.com,PROXY_MEETING
  - DOMAIN-SUFFIX,microsoft.com,PROXY_MEETING
  - DOMAIN-SUFFIX,office.com,PROXY_MEETING
  - DOMAIN-SUFFIX,office365.com,PROXY_MEETING
  - GEOIP,CN,DIRECT
  - MATCH,DIRECT

microsoft.com のような広いサフィックスは運用は楽ですが、会議以外のマイクロソフト系まで同じ出口に流れます。プロキシに載せる面を最小にしたい場合は、ログに繰り返し出るサブドメインに絞り、国内向けとプライベート IP の DIRECT を先頭で安定させてください。最終行の MATCH は自分の既定ポリシーに合わせてください。

動作モード：Rule・Global・Direct の位置づけ

Rule が基本です。Global は「すべてプロキシ」に近い状態で、短時間だけ試すと、ルール不足なのかノード品質なのかを切り分けしやすくなります。常時 Global にすると国内サイトまで遠回りになるためおすすめしません。Direct はベースライン計測用に、会議だけ Clash を事実上オフに近い状態にして比較します。ルールを書いたあとは、意図したルール行にヒットしているかをログで確認するのが定石です。

推奨の切り分け順：チケットを書くつもりでログを残す

  1. 変数を減らす：ブラウザの拡張プロキシや他社 VPN／加速器をいったん止め、Clash だけにする。
  2. 取り方を確かめる：システムプロキシと TUN を切り替え、会議クライアントの接続がログに出るか比較する。
  3. 再現してホスト名を拾う：参加から切断まで、失敗した瞬間の宛先ドメインとヒットしたルールをメモする。
  4. ルールか DNS を修正：誤ったポリシーに流れているならルールの順序やグループ名を直す。疑うなら DNS の上流・DoH・Clash の DNS 設定を一括で変えず、一か所ずつ試す。
  5. 同じノードで再現する：ノードの品質問題か、ルール／DNS かを分ける。

この「ログ駆動」は、開発者向け分流記事 や Gemini 向けの DNS 記事 と同じ骨格で、観察対象のホスト名だけがリモートワーク・ビデオ会議に変わります。

企業ネットワーク・社内 VPN と併用するとき

社内 VPN やゼロトラスト製品はルーティングを上書きします。Clash の TUN と競合する例もあります。まずは組織のセキュリティ規程を優先し、許可された範囲で社内イントラネットや社内ポータルを DIRECT に残す、といった設計をします。IT 部門の PAC やプロキシ説明がある場合は、会議に必要なドメインがそこに含まれているかと突き合わせるとよいです。

よくある質問

zoom.us を書いたのに会議に入れない

セッション中に別のサブドメインや別プロトコルが使われていることがあります。ログに出た実ホスト名を追加し、より上の行に優先度の高いルールを置くか、手前のルールに食われていないか確認してください。

Teams のログインは通るのに、会議に入ると断線する

メディア用のホストがルールに含まれていない、UDP が不利なノード、リアルタイム向きでない出口、などが考えられます。まずログでホストとヒットを確認し、ノードを固定して同じ操作を繰り返します。

TUN を有効にしたら国内サイトだけ遅くなった

GEOIP,CN,DIRECT やプライベート帯の DIRECT が先に効いているか、MATCH が国内までプロキシに流していないかを確認してください。詳しくは カスタムルール の順序の説明も参照してください。

まとめ

リモートワークで Zoom と Microsoft Teams を安定させるには、グローバルに近い一括プロキシから、会議に関係するホスト名だけを意図した出口へ分ける分流ルールと、それと矛盾しないDNS の設計が効きます。ホスト名リストはログで更新し続ける「生きた設定」として扱うのが、2026 年以降もクライアント更新に追従しやすいやり方です。

クライアントの入手は、記事と突き合わせやすいよう 本サイトのダウンロードページ を第一にし、基本操作は チュートリアル で押さえたうえで、本稿の手順で会議向けのルールと DNS を足すとよいでしょう。トンネル型 VPN よりも、ルールの見える化と切り替えのしやすさは Clash の強みです。→ Clash を無料ダウンロードし、リモート会議向けの分流と DNS を試す