在宅ワークのZoom・Slackを快適に使うClash分流設定ガイド

通信の分け方：会議通信と国内サイトを別の出口へ

在宅ワークでZoomやSlackを使うときは、すべての通信を同じプロキシ経由にするのではなく、会議・業務サービスと国内サイトを分けて考えると、速度と接続の安定性を両立しやすくなります。たとえばZoomとSlackは専用のプロキシグループへ送り、普段使う国内サイトや家庭内の機器は直接接続にする構成です。ただし、どの通信をプロキシへ送るべきかは、勤務先のネットワークポリシーやサービスの接続条件に従って決めてください。

Clashのルールは、通信先のドメインやIPアドレスなどを上から順に評価し、最初に一致したルールで出力先を決めます。ルールに書いたサービス名が、そのサービスのすべての通信を網羅するとは限りません。Zoomの会議では、ログイン画面や会議情報の取得に使うHTTPS通信に加え、音声・映像にUDPが使われることがあります。Slackも、メッセージ、ファイル、画像などで接続先が異なる場合があります。そのため、ルールを追加した後はクライアントの接続画面で、実際の接続先と適用ルールを確認することが重要です。

設定前の準備：コア、モード、グループを確認

設定例はmihomoコアを搭載したClashクライアントを想定しています。Clash Verge、Clash Verge Rev、Mihomoを使うクライアントなどでは、画面名や設定の適用方法が異なる場合があります。従来版Clashや独自フォークでは、対応するルール項目やTUNの挙動が異なることもあるため、最初に「バージョン情報」「コア情報」などで実際に使っているコアを確認してください。

1. 現在の設定またはプロファイルをエクスポートし、元に戻せるバックアップを保存します。
2. サブスクリプションが有効で、プロキシグループから利用可能なノードを選択できることを確認します。
3. クライアントの動作モードを「ルール」にします。「全体」では意図したDIRECTルールが期待どおりに使われず、「直接接続」ではプロキシグループを使った振り分けになりません。
4. ポリシーグループ名を確認します。設定例のグループ名が実際の設定に存在しない場合、ルールの読み込みに失敗したり、意図した出力先にならなかったりします。

会議専用のグループを作る場合は、設定済みのノード、または既存の自動選択グループを候補にします。以下の例では、ルールが参照するグループ名を 会議用 としています。この名前のグループをあらかじめ定義するか、すでに存在するポリシーグループ名に置き換えてください。グループ名は日本語でも設定できますが、YAMLのインデントや文字列の表記を崩さないようにします。

proxy-groups:
  - name: 会議用
    type: select
    proxies:
      - 自動選択
      - ノード名を選択
      - DIRECT

rules:
  - DOMAIN-SUFFIX,zoom.us,会議用
  - DOMAIN-SUFFIX,zoom.com,会議用
  - DOMAIN-SUFFIX,slack.com,会議用
  - DOMAIN-SUFFIX,slack-edge.com,会議用
  - DOMAIN-SUFFIX,slack-files.com,会議用
  - DOMAIN-SUFFIX,example.jp,DIRECT
  - MATCH,既存のデフォルトグループ

この例はルールとグループの書き方を示すもので、ZoomやSlackが利用する全ドメインを網羅するリストではありません。example.jp は説明用の例なので、実際に直接接続したいことを確認できたドメインだけに置き換えてください。すでにプロファイルに rules がある場合は、同じトップレベル項目を重複して作らず、既存のルールリストに必要な行を追加します。MATCH は最後に置き、既存のデフォルトグループ名を正確に指定してください。

DOMAIN-SUFFIX,zoom.us は zoom.us とそのサブドメインに一致しますが、似た文字列の別ドメインには自動で一致しません。Slackについても、例に含めたドメインだけでファイル転送や画像表示が必ずカバーされるわけではありません。接続先が不足していると判断した場合は、接続ログに表示された実ドメインを確認し、必要なものだけを追加します。根拠なく広いドメイン範囲を会議用グループへ送ると、関係のない通信までプロキシ経由になることがあります。

操作手順：会議を開始してからログを見て調整

一度にルール、DNS、TUN、システムプロキシをすべて変更すると、問題が起きたときに原因を切り分けにくくなります。まずバックアップを取り、ルールモードとノードの接続を確認したうえで、必要な設定を段階的に反映します。クライアントに「オーバーライド」「拡張設定」「ルール編集」などがある場合は、サブスクリプション更新後も変更が保持される方法を選んでください。配布された設定ファイルを直接編集すると、更新時に変更が上書きされることがあります。

1. 設定編集画面で、会議用グループが参照できることを確認します。候補として登録したグループやノード名は、実際の設定と完全に一致させます。
2. ZoomとSlackのルールを、広い範囲を指定するルールや MATCH より前に追加します。国内向けのDIRECTルールを使う場合も、対象を確認したうえで、汎用ルールより前に置きます。
3. 設定を保存し、クライアントが構文エラーを表示しないことを確認します。設定の再読み込みを行った場合は、モードが「ルール」のままであることも確認してください。
4. Zoomを開き、テスト会議で音声と映像を確認します。同時に接続画面またはログを開き、Zoom関連の接続が表示されるか、適用ルールと出力先が想定どおりかを確認します。
5. Slackでメッセージ送信、画像表示、ファイルのアップロードまたはダウンロードを個別に試します。機能ごとに接続先や結果が異なる場合は、それぞれのログを確認します。
6. 最後に普段使う国内サイトを開き、直接接続にした対象が想定どおり表示されるか、読み込み時間に変化がないかを比較します。

Zoomの画面が表示されても、音声・映像の経路が正しく動作しているとは限りません。参加者一覧は使えるのに音声が途切れる、映像だけが不安定になる場合は、接続ログでTCPとUDPの通信状況を区別して確認します。TUNを使っていない環境では、アプリがOSのシステムプロキシを利用せず、Clashの接続画面に一部の通信が現れないことがあります。その場合は、すぐに全体モードへ切り替えるのではなく、クライアントとアプリのプロキシ対応、TUNの設定、勤務先の指定を確認してください。

UDPとTUN：会議の音声・映像が不安定なとき

Zoomの音声・映像では、ネットワーク状況に応じて通信方式や接続先が変化することがあります。HTTPプロキシを設定しただけで、すべてのUDP通信が同じ経路に入るわけではありません。デスクトップアプリがシステムプロキシを利用しない場合や、UDP通信がプロキシ経由で扱えない場合には、ブラウザーでWebページを開けても会議だけ失敗することがあります。まずクライアントの接続一覧に会議中の通信が現れるか確認し、見つからない場合は「Clashに届いていない問題」と「Clashに届いた後の出力先の問題」を分けて調べます。

TUNは、通常のシステムプロキシを利用しないアプリの通信も仮想ネットワークインターフェース経由で取り込むための機能です。ただし、TUNを有効にすればどの通信も必ずプロキシへ送られるわけではありません。ルールがDIRECTを指定していれば直接接続になり、ドメインを取得できない通信では想定したドメインルールに一致しないこともあります。TUNを試すときは、利用中のクライアント、OS、mihomoコアの対応状況を確認し、既存のVPNを停止または併用してよいかも確認してください。

会議用グループの中でノードを選ぶ際は、遅延テストの数値だけで判断しないでください。遅延テストは指定されたURLへの応答時間を示すもので、会議中のUDP品質、パケット損失、混雑時の帯域を保証しません。候補のノードを一つずつ使い、同じ時間帯、同じ会議条件で音声の途切れや画面共有を比較します。接続出口が変わるとサービス側の認証やセッションに影響する場合もあるため、会議中に頻繁にノードを切り替えるのは避けましょう。

問題が起きたときは、システムプロキシの状態、ルールモード、選択中の設定、会議用グループのノード、ログに出たルールと出力先を順番に記録します。原因の確認に不要な設定変更を重ねず、変更前に保存したプロファイルへ戻せる状態を保つことが、在宅勤務の通信を安定して運用する基本です。