はじめに
在宅勤務中のビデオ会議では、映像の乱れだけでなく、音声の途切れや画面共有の遅れも業務に影響します。一方、すべての通信をプロキシ経由にすると、普段利用する国内サイトまで遠回りになり、かえって遅くなることがあります。そこで役立つのが、通信先に応じて経路を選ぶ Clash のルールベース分流です。
この記事では、Zoom、Google Meet、Slack の通信を専用のプロキシグループへ振り分け、日本国内のサイトや一般的な国内通信は DIRECT にする構成を紹介します。Clash Verge Rev や Mihomo 対応クライアントを想定していますが、基本的な考え方はほかの Clash 系クライアントでも共通です。
この記事の目標
会議アプリの通信経路を管理しつつ、国内サイトへの接続を不必要にプロキシへ通さない設定を作ります。なお、実際の品質は回線、ノード、会議サービス側の状況にも左右されます。
1設定前に確認すること
ルールを追加する前に、利用中のクライアントが現在のプロファイルを正常に読み込んでいるか確認してください。Clash のルールは上から順に評価され、最初に一致したルールが適用されます。また、プロバイダーのサブスクリプションを更新すると、手動で変更した設定が消える場合があります。元の YAML を複製して保存し、プロファイルの編集画面や Merge（マージ）機能など、クライアントが推奨する方法で変更するのが安全です。
- コアを確認：使用中のコアが Mihomo など、設定に使うルール形式に対応していることを確認します。
- プロキシグループを確認：現在の設定に会議向けのグループがあるか調べます。なければ、追加するグループ名とルール内の名前を一致させます。
- 接続条件を確認：プロバイダーが UDP 通信を扱えるか、利用するノードが UDP に対応しているかを確認します。対応状況はサービスやノードによって異なります。
- 変更前の状態を記録：元のルール、選択中のノード、会議時の症状を控えておくと、設定後に問題が出た際に戻しやすくなります。
注意
Clash のルールだけで会議の遅延が必ず解消するわけではありません。ネットワークが混雑している場合や、ノードまでの経路に問題がある場合は、別の回線やノードとの比較も必要です。
2会議用グループとノードを選ぶ
Zoom や Google Meet の通信先を個別のノード名に直接結び付けるより、まず Work のようなプロキシグループを作ると管理しやすくなります。会議サービス用ルールはこのグループを指定し、実際に使うノードはクライアントの「プロキシ」画面から選びます。ノードを交換してもルールを毎回書き換えずに済みます。
上記のノード名は例です。実際には、プロファイルに存在する名前へ置き換えてください。利用中の設定に proxy-groups がすでにある場合は、同じ名前のグループを重複して追加せず、既存グループを再利用するか、プロファイルの仕組みに合わせて変更します。選択肢に DIRECT を加えるかどうかは、会議サービスを直接接続した場合の動作やネットワークポリシーを確認して判断してください。
ノード選びでは、表示される遅延値だけを基準にしないことが大切です。会議では瞬間的な速度より、音声・映像が途切れにくいことや、遅延の変動が小さいことが重要です。候補を一つずつ選び、同じ時間帯に短いテスト会議を行って、音声、映像、画面共有を比較します。選択式のグループで複数ノードを切り替えられるようにしておけば、障害時の切り分けにも役立ちます。
UDP対応を確認
ビデオ会議の通信には UDP が使われる場合があります。クライアントやコアの設定だけでなく、ノード側も含めて UDP が利用できるか確認してください。対応していない場合、接続できても品質が期待どおりにならないことがあります。
3Zoom・Google Meet・Slackを分流する
次の例は、会議サービスや仕事用ツールとして識別したい通信を Work グループへ振り分けるルールの一例です。使用するルールセットの名前や設定場所はクライアント、プロファイルによって異なるため、既存の構造に合わせて追加してください。以下のドメインは出発点であり、すべての機能・通信先を網羅するものではありません。
最後の MATCH は例示です。必ず現在のプロファイルで利用している既定グループ名に置き換えてください。国内向けルールを追加するときも、既存のルールと順序を確認します。特定のサービスをプロキシへ通したいのに、それより前の広い条件で DIRECT が選ばれると、会議用ルールまで到達しません。
Zoom のドメインを指定しても、接続先がドメインルールに一致しない場合や、IP アドレスで処理される通信が残ることがあります。Google Meet も Google の共通インフラを利用するため、google.com や googleapis.com を広く指定すると、会議以外の検索、メール、その他の Google サービスまで同じ経路に流れる可能性があります。範囲をむやみに広げず、まず必要なドメインだけを対象にし、問題が残る場合にログを見て追加する方法が安全です。
国内サイトを直接接続する方法は、利用中のルールセットに応じて選びます。Mihomo のルールプロバイダーに国内向けルールが含まれるなら、それを活用できます。手動で GEOIP,CN,DIRECT を追加する場合は、IP 判定に頼るルールであることを理解し、既存の DNS 設定やルールとの整合性を確認してください。すべての国内サービスを必ず正しく識別できるとは限りません。
ルール順序のポイント
会議アプリなど個別に経路を指定したいルールを、対象通信を広く拾う国内・一般ルールより前に置きます。設定の読み込み後は、接続ログで実際に一致したルールと選ばれたグループを確認してください。
4動作確認とトラブルシューティング
YAML を変更したら、すぐに長時間の会議で試すのではなく、まず設定が有効かを確かめます。クライアントで設定を検証または再読み込みし、エラーが出た場合はインデント、グループ名、ノード名を見直してください。YAML は空白のずれや、存在しないプロキシ名だけでも読み込みに失敗することがあります。
- 会議サービスのアプリまたはウェブ版を起動し、Clash の接続ログを表示します。
- Zoom または Meet の会議に参加し、関連する通信が想定したルールと
Workグループに一致しているか確認します。 - グループ内のノードを一つずつ切り替え、同じ条件で音声、映像、画面共有を比較します。
- 国内サイトを開き、意図せずプロキシ経由になっていないか、接続ログとあわせて確認します。
- Slack のメッセージ送信、ファイル表示、通知も確認し、必要な通信が漏れていないかを調べます。
| 症状 | 確認する項目 | 試すこと |
|---|---|---|
| 会議に参加できない | ルールの一致先、ノードの状態、UDP対応 | ログで経路を確認し、別のノードでも比較する |
| 映像や音声が不安定 | パケットロス、回線混雑、遅延の変動 | 有線接続や別ノードを試し、他の通信も一時停止する |
| 国内サイトまで遅くなった | 広すぎるドメイン指定、国内ルールの順序 | 対象範囲を絞り、ログで DIRECT になっているか確認する |
| Slackの一部だけ読み込めない | 関連ドメインが別ルールに一致していないか | ログから実際の接続先を調べ、必要なものだけ追加する |
問題の原因を切り分ける際は、ルールを一度に大量に追加しないでください。一つ変更するたびに設定を再読み込みし、同じ操作で改善したかを確かめると、どの変更が影響したのか分かりやすくなります。会議アプリのアップデートやサービス側の変更で接続先が変わることもあるため、以前動いていた設定が将来もそのまま有効とは限りません。
最終的には、会議用グループを適切なノードへ切り替えられる状態にし、ログでルールの一致を確認できるようにしておくことが実用的です。プロファイル更新後にルールが残っているかも点検してください。職場のネットワークポリシーや利用地域のルールがある場合は、それらを優先し、組織が許可した接続方法を利用しましょう。