Zoom、Teams、Slack を Clash で振り分ける方法：リモート会議とログインのトラブルシューティング

Zoom、Teams、Slack はいずれも業務用ソフトウェアですが、ログイン、チャット、ファイルのダウンロード、会議の音声と映像、社内ネットワークは同じ接続を使用しません。すべての業務用ドメインを一つのノードグループへ入れるのではなく、まずログインを安定させ、その後 UDP 会議と WebSocket を個別に検証してください。これにより、「ログインできても会議へ入れない」場合と「会議は正常でも添付ファイルを開けない」場合を、それぞれ別の入口から調査できます。

ドメインルールはログインと通常の HTTPS に適していますが、メディア通信では UDP、企業ファイアウォール、アプリケーションプロセスも考慮する必要があります。公式に管理されている IP 一覧を個人用 YAML へ恒久的にコピーしないでください。Zoom と Microsoft はどちらも範囲を更新するため、企業環境では管理者が公式一覧を購読する必要があります。

チャット、ファイル、ログインでは出口の安定性が重要で、会議では UDP、アップロード速度、ジッターがより重要です。Work-Web で通常のリクエストを管理し、Meeting では UDP の動作を確認済みのノードを選択できます。会社のネットワークで Zoom または Teams のメディアを直接接続できる場合は、Meeting グループにも DIRECT を残してください。

二つの REPLACE_WITH 名を、現在の設定に実在するノード名へ置き換える必要があります。元の設定にフォールバックポリシーがある場合は、最後の MATCH,DIRECT を以前の MATCH ルールへ戻してください。まずポリシーを手動で固定し、会議の途中で出口が自動的に切り替わらないようにします。

ブラウザで zoom.us を開けても、HTTPS のログイン入口へ到達できることしか証明できません。会議へ入った後も Connecting のままになる、映像は見えても音声が聞こえない、共有を始めて数分後に切断される、といった場合は、Clash の接続ページとファイアウォールログで UDP を確認してください。Zoom の公式情報で現在示されている会議メディア用ポートには、UDP 3478-3479 と 8801-8810 が含まれます。

個人のネットワークでは、同じノードで Zoom の音声と共有を先にテストできます。企業ネットワークでは IP の許可リスト一式を独自にコピーせず、Zoom の公式ページに基づく管理を管理者へ依頼してください。ノードが UDP に対応していない場合、Web プロキシを切り替えても会議メディアは修正できません。

Teams のログインは Microsoft の認証サービスを経由し、チャットとファイルは SharePoint または OneDrive へ接続する場合があります。リアルタイムメディアでは、さらに別のエンドポイント群を使用します。Microsoft の 2026 年版ネットワークガイドでも、メディアをプロキシの対象外にして経路をできるだけ短くし、UDP 3478-3481 を許可することが引き続き推奨されています。

会社がプロキシまたは SSL 検査を必須としている場合は、組織のポリシーに従ってください。個人の Clash ルールで、会社の VPN が配布したプライベートネットワークと内部 DNS を上書きすべきではありません。Web ページとチャットが正常な場合は、会議の遅延を理由に Microsoft 365 のすべてのトラフィックを別の地域へ切り替えないでください。

Slack で特に分かりやすい問題は、Web ページが開けないことではなく、メッセージ領域の上部に再接続のメッセージが繰り返し表示されることです。まず公式の接続テストで WebSocket を確認してから、SSL 検査の調整を管理者へ依頼する必要があるか判断します。

コンピューターから会社の VPN にも接続する必要がある場合は、会社から配布されたプライベートネットワークと内部 DNS を優先して維持してください。Clash では本当に必要な外部 Web ページだけを処理するほうが、二つの仮想ネットワークインターフェースでデフォルトルートを奪い合うより安定します。