会議アプリごとに通信を分けるメリット
Zoom・Slack・Google Meet の音声や映像が不安定なとき、すべての通信を同じプロキシへ送るだけでは原因を切り分けにくいことがあります。社内チャットは問題なくても、Meet の画面共有だけ遅れる、Zoom の接続先を変えたら音声が途切れる、といった症状は、アプリごとの通信先や経路の違いから起こる場合があります。
Clash のルール分流を使えば、会議アプリの通信を専用のプロキシグループへ送り、通常のウェブ閲覧や社内サービスは DIRECT にする、といったポリシーを組み立てられます。ここでいう「使い分け」は、アプリ名だけで通信を完全に識別するという意味ではありません。Clash の一般的なルールはドメインや IP アドレスなどを基準に判定するため、同じアプリでも認証・通話・画像配信で別のホストへ接続することがあります。
本稿では Clash Verge Rev と Mihomo 系のルール設定を例に、会議向けグループの考え方、Zoom・Slack・Meet のルールを加える手順、ログと接続テストによる確認方法を解説します。画面の項目名はクライアントやバージョンによって異なるため、ボタン名が一致しない場合は「プロファイル」「ルール」「接続」など同等の画面を探してください。基本的な画面操作はClash Verge Rev のチュートリアルも参考になります。
会議用のプロキシグループとルールを設計する
最初に決めるのは、どのアプリを必ずプロキシへ送るかではなく、どの症状を改善したいかです。社内ネットワークから Zoom の接続先に到達しにくいなら Zoom 関連だけを対象にし、Meet や Slack が安定しているなら、初期設定では既存の経路を変えないほうが安全です。対象を増やすほど、遅延や認証トラブルが起きたときに原因を追いにくくなります。
会議用のグループは、手元の設定にすでにあるプロキシグループを利用するか、プロファイルが許す場合に専用の選択グループとして用意します。グループ名はサンプル設定と自分の YAML の両方で一致させてください。以下は書式を示す例です。会議用は実際に存在するグループ名へ置き換え、利用中のプロファイルに合わせて編集します。
proxy-groups:
- name: 会議用
type: select
proxies:
- ノードA
- ノードB
- DIRECT
rules:
- DOMAIN-SUFFIX,zoom.us,会議用
- DOMAIN-SUFFIX,slack.com,会議用
- DOMAIN-SUFFIX,meet.google.com,会議用
- MATCH,既定のポリシーこれは考え方を示す例であり、Zoom・Slack・Meet のすべての通信先を網羅するリストではありません。認証、WebSocket、会議の中継、添付ファイルや映像配信は別のドメインを使うことがあります。反対に、Google 系の広いドメインをまとめてプロキシへ送ると、Gmail や検索など会議と関係のない通信まで経路が変わる可能性があります。ドメインを追加する場合は、接続ログに出た名前とアプリの利用状況を照らし合わせ、必要性を確認してから少しずつ加えます。
- まずは狭く始める：問題が出ているサービスの代表的なドメインから追加し、他のサービスへ一括適用しない。
- ルールの順序を確認する：対象ルールは、最終的な
MATCHなどの包括ルールより上に置く。 - DIRECT も選択肢に残す：プロキシ経由で遅くなる環境では、会議用グループ内で DIRECT とノードを比較できるようにする。
- 会社のポリシーを優先する：業務端末や社内 VPN の設定を変更する前に、管理者のルールや情報セキュリティ要件を確認する。
ルールを編集する画面が読み取り専用の場合、購読プロファイルを直接書き換えるのではなく、クライアントが提供するオーバーライドやマージ設定を利用してください。配布元が更新したプロファイルを再取得すると手作業の変更が消えることがあります。変更前の設定を保存し、元に戻す手順を確保しておくと、会議直前のトラブルにも対応しやすくなります。
動作確認：ルール追加から会議テストまで
設定を一度に大きく変えず、対象サービスを一つずつ確認します。テストは実際の会議の直前ではなく、短いテスト通話や社内の検証時間を使って行うのがおすすめです。プロキシノードを選んだ状態だけでなく、DIRECT に戻した場合も比較できるよう、開始前の状態をメモしておきます。
- 現在の状態を記録する：Clash のモード、選択中のグループ、システムプロキシや TUN の状態を控えます。別の VPN やプロキシを同時に有効にしている場合は、競合の可能性も確認します。
- 会議用グループを決める：既存グループを使うか、プロファイルで許可される範囲でグループを追加します。候補ノードの遅延だけでなく、会議時に音声が途切れないか、画面共有が安定するかも評価します。
- 対象ルールを限定して追加する：Zoom など、症状があるサービスからルールを加えます。ルールを保存またはプロファイルへ反映し、設定の構文エラーがないことを画面で確認してください。
- 接続ログを見ながらアプリを使う：会議への参加、音声の有効化、画面共有などを順に試します。ログに表示される接続先、適用されたルール、選択されたポリシーを確認し、意図したグループへ流れているかを見ます。
- 結果を比較する：同じネットワークと会議条件で、選択したノードと DIRECT の状態を比較します。遅延テストの数値だけで結論を出さず、音声の途切れ、映像の停止、再接続の有無を確認します。
アプリが会議に参加できても、ログに対象ルールが出ない場合は、別の通信先が使われているか、別のルールが先にマッチしている可能性があります。逆に、認証ページだけが失敗するなら、会議本体ではなくログイン関連の通信経路を調べます。ログに現れたホスト名をそのまま追加する前に、ドメインの用途を確認してください。共有サービスのドメインを安易に登録すると、関係のない通信まで会議用ポリシーへ送られることがあります。
会議中だけ症状が出る場合は、短時間の確認だけでなく、実際の会議に近い条件で数分間テストします。参加者が多い会議、画面共有、カメラのオン・オフで通信量や接続先が変わることがあります。問題が再現した時刻をメモし、その前後のログと照合すると、単なるノードの遅さなのか、特定の接続先だけが失敗しているのかを判断しやすくなります。
Zoom・Slack・Google Meet で気を付けたい点
Zoom：会議中継と通常のウェブアクセスを分けて考える
Zoom のウェブサイトが開けることと、会議の音声・映像が安定することは同じではありません。会議では参加者の地域や接続方法に応じて中継先が選ばれるため、ブラウザでトップページを表示しただけでは通話経路を検証できません。ログに Zoom 関連の接続が出ているか確認し、接続先が変わった場合にも同じポリシーが適用されるかを見ます。会社指定の Zoom 設定や VPN がある場合は、勝手に経路を置き換えないでください。
Slack：メッセージとハドルの挙動を別々に見る
Slack のメッセージ送受信が正常でも、ハドルや音声・映像だけが不安定になることがあります。テキスト表示、ファイル添付、ハドル参加をそれぞれ試し、問題がどの操作で発生するか記録しましょう。必要な接続先はアプリのバージョンや組織の設定によって変わり得るため、一般的なドメイン一覧だけを根拠に広いルールを追加するのは避けます。社内 Slack の通信を DIRECT にする必要がある組織では、プロキシへ送るルールが業務ポリシーに反しないかも確認します。
Google Meet：Google 全体をまとめて迂回しない
Meet の会議ページに関連する接続先と、Google アカウントの認証、カレンダー、Gmail などは重なることがあります。Meet のために Google のドメイン全体をプロキシへ送ると、会議以外のサービスにも影響する可能性があります。まず会議への参加や画面共有で再現する症状を確認し、Clash のログに表示される実際のホストを手がかりに範囲を絞ります。学校や会社のアカウントで利用する場合、管理対象のネットワーク設定を優先してください。
どのアプリでも、Clash のルールだけで通話品質が必ず改善するわけではありません。Wi-Fi の電波、回線混雑、端末の負荷、マイクやカメラの状態、会議サービス側の障害も影響します。プロキシを切り替えるときは一項目ずつ変更し、改善しなければ元に戻して別の要因を確認します。TUN はシステムプロキシを使わない通信にも対応できる一方、社内 VPN やセキュリティ製品と競合することがあるため、最初の解決策として常時有効にするのではなく、必要性と組織の許可を確認してから試してください。
単一の会議アプリだけを切り替える専用ツールは手軽な反面、アプリごとの例外設定が少なかったり、通常のウェブ閲覧との経路をまとめて管理しにくかったりすることがあります。Clash ならルール、プロキシグループ、接続ログを組み合わせ、Zoom・Slack・Meet を個別に検証しながら調整できます。設定の変更履歴を残し、会議ごとに適用状況を確かめる運用にすれば、原因の説明と切り戻しもしやすくなります。複数のアプリと通常の閲覧を一つのポリシーで整理したい場合は、利用する端末に合った Clash クライアントを確認してみてください。