仕事の通信を分ける前に決めておくこと
ZoomやSlack、Google Meetの通信をClashで分ける場合、最初に決めるのは「どのサービスをプロキシへ送るか」だけではありません。会議の音声・映像を安定させる出口、普段のWeb閲覧に使う経路、社内システムや業務用VPNとの優先関係を整理します。ルールを追加しても回線自体の混雑やWi-Fiの電波状況は改善しません。用途に合うノードを選び、どの通信がそのノードを通るかを確認するための設定と考えてください。
この記事の例はmihomo系コアを想定しています。Clash Verge Revなどのクライアントでは、画面名や設定の編集方法が異なります。クライアントのバージョンとコアのバージョンも別の情報です。設定項目を追加する前に、実際に起動しているコアと、適用後の最終設定を確認してください。サブスクリプションを更新すると手動編集が上書きされる場合があるため、クライアントのオーバーライド機能やマージ機能を使うのが基本です。
| 通信・用途 | 最初に試す経路 | 注意点 |
|---|---|---|
| Zoomの会議 | 安定した近距離のプロキシグループ | 会議の音声・映像でUDPが使われる場合がある。ノードとコアのUDP対応も確認する |
| Slackのメッセージ・ファイル | Zoomと同じグループ、または別の業務用グループ | 通信先ドメインは機能によって異なり、一覧だけで完全に網羅できるとは限らない |
| Google Meet | 会議向けグループ | Googleの共通ドメインを広く指定すると、会議以外のGoogle通信まで同じ経路に入る可能性がある |
| 社内システム・社内VPN | 会社の指定に従う | 会社管理端末では、Clashや個人プロキシの利用可否を事前に確認する |
| 通常のWeb閲覧 | 既存のルールと既定ポリシー | 業務用ルールを追加しただけで、ほかの通信の挙動まで変わるとは限らない |
会議用グループとルールの基本
会議用には、単独のノード名をルールに直接書くより、選択型のプロキシグループを用意する方法が扱いやすいです。会議中に出口を切り替える必要が生じたとき、グループの選択先だけを変えられます。既存の設定に会議向けのグループがある場合は、新しいグループを重複して作らず、そのグループ名をルールから参照してください。以下は構造を示す例です。ノード名は利用中の設定に存在するものへ置き換え、同じ名前のグループをすでに定義していないか確認します。
proxy-groups:
- name: WORK-MEETING
type: select
proxies:
- Node-A
- Node-B
- DIRECT
rules:
- DOMAIN-SUFFIX,zoom.us,WORK-MEETING
- DOMAIN-SUFFIX,zoom.com,WORK-MEETING
- DOMAIN-SUFFIX,slack.com,WORK-MEETING
- DOMAIN-SUFFIX,meet.google.com,WORK-MEETING
- MATCH,PROXYNode-A、Node-B、PROXYは説明用の名前です。実際の設定にあるプロキシ名やポリシーグループ名と一致させてください。最後のMATCHは、それより前のルールに該当しない接続を処理するための例です。元の設定にある最終ルールを不用意に置き換えず、業務用のルールはその前に追加します。ルールは上から評価されるので、先に広い条件を置くと、その下の細かい条件が使われないことがあります。
ドメインルールが振り分けるのは、コアがドメイン名を把握できた接続です。IPアドレスだけで接続する通信や、DNS情報と接続の対応をコアが保持できない通信では、ドメイン条件に一致しない可能性があります。DOMAIN-SUFFIX,google.comのような広い条件を追加すると、Meet以外のGoogleサービスも対象になり得ます。必要な範囲を絞り、接続ログで実際の通信先を確認してから補うのが安全です。
UDPと通信の取り込みを区別する
Zoomなどの会議では、音声や映像にUDPが使われることがあります。通常のシステムプロキシ設定は、すべてのアプリやUDP通信を自動的にClashへ取り込む仕組みではありません。対象アプリがシステムプロキシを使うか、TUNモードで通信を取り込めているか、使用中のコアとノードがUDP転送に対応しているかを別々に確認します。ルールに会議サービスのドメインを追加しただけでは、取り込み経路がない通信まで制御できるわけではありません。
会議が始まると映像だけ止まる、音声が途切れる、画面共有の開始に時間がかかるといった場合は、出口の遅延だけでなく、UDPの到達性、TUNの状態、ほかのVPNとの競合も確認してください。UDPが利用できない環境ではサービスがTCPへ切り替えることがありますが、その切り替えが必ず成功するとは限らず、遅延や品質の低下が残ることもあります。
実際に設定し、会議で検証する
変更は一度に一つずつ行います。最初からZoom、Slack、Google Meetの全ドメインを追加したり、DNS設定やTUN設定も同時に変更したりすると、原因を追いにくくなります。現在のプロファイルをバックアップし、まず会議用グループと一つのサービスのルールから試してください。
- コアと現在のモードを記録：クライアントのコア情報でmihomoなどの名称とバージョンを控えます。現在のモード、システムプロキシの状態、TUNの有効・無効、同時に動作しているVPNも記録します。
- 会議用グループを確認：既存の選択型グループを使うか、設定に一つ追加します。利用できるノードを2つ程度選び、グループ名と参照先の名前が一致していることを確認します。
- ルールを少数追加：最初は実際に使うサービスのドメインだけを、既存のルール群の適切な位置に追加します。社内向けの例外ルールや、より具体的なドメインルールより後ろに置かないよう注意します。
- 設定を適用：クライアントの設定チェックや再読み込みを実行します。YAMLのインデント、重複キー、存在しないグループ名のエラーがないことを確認してから、コアを再起動します。
- 接続ログを確認：ZoomやSlackを起動し、ログまたは接続一覧で通信先のドメイン、選択されたポリシー、接続の成否を確認します。ルールに一致しない通信があれば、その接続先を確認したうえで必要な条件だけを追加します。
- 会議中に比較：同じ時間帯、同じ端末、同じネットワークで、候補ノードを一つずつ試します。音声の途切れ、映像の停止、画面共有、会議への再接続を記録し、測定値だけでなく実際の会議品質で選びます。
クライアントによってメニュー名は異なりますが、設定画面や接続ログ、コアログを見られる場所を使います。接続一覧に出るポリシー名が想定と違う場合は、まず一致したルールとその順番を確認します。接続がログに現れない場合は、ルールを書き換える前に、アプリの通信がシステムプロキシまたはTUNに取り込まれているか調べてください。ログを共有して相談する際は、サブスクリプションURL、ノードのアドレス、認証情報、社内ドメインやユーザー名を伏せます。
不安定なときの切り分けと運用
| 症状 | 確認する順序 | 次の対応 |
|---|---|---|
| ルールを追加しても接続が直接になる | 接続がClashに取り込まれているか、ドメインが判明しているか、ルールの順序は適切か | 接続ログとTUN・システムプロキシの状態を調べ、実際に一致したルールを確認する |
| 会議に入れるが音声や映像が途切れる | UDP対応、ノードの負荷、Wi-Fi品質、他のVPNやネットワーク制御 | 近距離の別ノードを試し、有線接続やWi-Fi帯域の変更も比較する |
| Slackの一部機能だけ読み込めない | 失敗した機能の接続先ドメイン、DNS応答、該当ルールのポリシー | ログで必要な接続先を特定し、確認できたドメインだけを追加する |
| 設定更新後に振り分けが戻る | サブスクリプション更新時の上書き、マージ設定、現在選択中のプロファイル | 永続化できるオーバーライド方法を使い、更新後の最終設定を再確認する |
| TUNを有効にすると社内サービスに接続できない | 会社のVPN要件、ルートの競合、DNS設定、許可されている構成 | 勤務先のIT部門に確認し、許可されない場合はTUNを無効にして元の状態へ戻す |
設定変更後は、会議以外の通信も数件確認します。通常のWeb閲覧、社内サイト、ファイル共有が意図しない出口に送られていないかを見てください。特に、ドメイン条件を広げた場合は、同じドメインを使う別サービスまで対象になっていないか確認が必要です。必要以上に全通信をプロキシへ通す構成にせず、業務の要件と勤務先の規則に合わせて範囲を調整します。
会議用ノードを変更するときは、変更日時、選択したグループ、会議で確認した症状を簡単に記録しておくと、次の不調時に比較しやすくなります。自動選択グループを使う場合でも、遅延テストの結果だけで会議品質が保証されるわけではありません。会議の開始前に接続ログを確認し、音声と画面共有を短くテストする運用を取り入れると、設定ミスを本番中に発見するリスクを減らせます。