在宅勤務のZoom・Slackを快適にするClashの分割設定ガイド

在宅勤務の基本方針：Zoom・Slackだけを振り分ける

在宅勤務でClashを使うときは、すべての通信を同じ経路に送るのではなく、業務アプリと国内向け通信を分けると管理しやすくなります。たとえば、ZoomとSlackは選択したプロキシグループへ送り、国内のWebサイトや家庭内LANは直接接続し、それ以外の通信は普段使っているルールに任せる構成です。

ここでいう「Zoom・Slackの通信」は、アプリ名だけで判定されるわけではありません。Clashのルールは主に接続先ドメインやIPアドレスなどを照合します。アプリが複数のAPI、CDN、メディアサーバーに接続する場合、サービスの代表ドメインを1つ指定するだけでは、すべての接続を同じ経路にできないことがあります。また、サービス側のドメイン構成は変更される可能性があるため、設定例をそのまま完全なリストとして扱わないでください。

ドメインルールの作り方：広げすぎず、既存設定に統合

Zoomではzoom.usやzoom.com、Slackではslack.comなどが接続先として使われることがあります。ただし、これらは設定を検討するための例であり、各サービスの通信先を網羅する保証はありません。特に会議の映像・音声は、ログイン画面やチャットとは異なる接続先を利用する場合があります。まずClashの接続履歴で実際の通信先を確認し、必要なドメインだけを追加してください。

DOMAIN-SUFFIX,zoom.us,業務プロキシは、zoom.usとそのサブドメインに一致します。ドメイン欄にはhttps://、ポート番号、URLのパスを含めません。サービスのルートドメイン全体を対象にするため、影響範囲が広すぎないかも確認しましょう。プロキシグループ名は、設定内のproxy-groupsにある名前と大文字・小文字を含めて一致させます。

以下は、既存のmihomo設定へ統合するルール部分の例です。業務アプリ向けの行を既存の国内向けルールやフォールバックより前に置き、実際に使っているグループ名とルールに合わせて編集してください。設定全体を置き換えるための完全なYAMLではありません。

mode: rule

rules:
  - DOMAIN-SUFFIX,zoom.us,業務プロキシ
  - DOMAIN-SUFFIX,zoom.com,業務プロキシ
  - DOMAIN-SUFFIX,slack.com,業務プロキシ
  # 既存の国内向け・LAN向けルールをここに維持
  # 既存のフォールバックルールは最後に維持

• サブスクリプションを直接編集しない：リモート設定の更新時に変更が上書きされることがあります。クライアントのオーバーライド、マージ、ローカル拡張機能が使える場合は、そちらに追加してください。
• 既存のルール順を保つ：ルールは通常、上から順に評価されます。先に一致したルールが適用されるため、業務アプリ用ルールをMATCHなどの広い条件より後ろに置くと、到達しないことがあります。
• 国内直結ルールを残す：業務用の設定を追加するために、既存の国内サイト、LAN、社内ネットワーク向けルールを削除しないでください。社内サービスが家庭内LANと同じプライベートIP範囲を使う場合は、接続環境に合わせて経路を確認します。
• YAMLの構文を確認する：インデントはスペースでそろえ、ルール内の区切り文字とグループ名を確認します。適用後はクライアントが設定を再読み込みできたか、エラーが出ていないかを確かめてください。

設定を追加して検証する：会議前に小さく試す

設定変更は、Zoom会議の直前ではなく、短いテスト時間を確保できるときに行います。サブスクリプションの元設定を保存し、変更前後を比較できるようにしてください。Clash Verge、Clash Verge RevなどGUIの表示名はバージョンによって異なります。以下は画面の名称に依存しない手順です。

1. 現在の状態を記録する：使用中のクライアントとコア、選択中の設定、ルールモードかどうか、業務用プロキシグループで選ばれているノードを確認します。ノードが停止中、またはグループがDIRECTになっていると、ルールの追加だけでは意図した経路になりません。
2. ローカル変更としてルールを追加する：利用中のクライアントにオーバーライドやマージ機能があれば、ZoomとSlackの必要なドメインを追加します。手動編集が必要な場合は、元ファイルのコピーを先に保存し、既存のルールとフォールバックを残します。
3. 設定を再読み込みする：クライアントで設定を適用し、構文エラーがないことを確認します。ルールモードを選び、ルール画面に追加した条件が表示されるか、参照先のプロキシグループが存在するかを見ます。
4. ZoomとSlackを個別に起動する：まず一方のアプリだけを開き、接続履歴またはルール欄で一致したドメイン、適用ルール、選択された出力先を確認します。もう一方も同じ手順で調べ、異なる接続先があれば必要性を確認してからルールを追加します。
5. 国内接続とLAN接続も試す：国内サイトが想定どおり直結し、家庭内のプリンターやルーター管理画面などが引き続き使えるか確認します。業務アプリだけが通ればよいと考えて他の経路を省略せず、日常利用への影響もテストしてください。
6. 変更を保存して戻し方を決める：接続できない場合に備え、追加したルールを削除するか、変更前の設定へ戻す方法を確認します。テストが終わったら、無関係なグローバルモードやTUN設定を変更したままにしないようにします。

この方法では、ドメインルールが一致したかと、プロキシグループが正常に接続できるかを別々に確認できます。ルール一覧に項目が表示されるだけでは、アプリの通信が実際にそのルールへ届いているとは限りません。接続履歴にルール名と出力先が記録されているかを判断材料にしてください。

会議中の音声・映像と接続トラブルの切り分け

Zoomの会議では、Webページやチャットの確認だけでは不十分です。映像・音声のリアルタイム通信はUDPを使うことがあり、HTTPのシステムプロキシだけではその通信を取り込めない場合があります。対象接続を取り込むTUNなどの機能が必要になることもありますが、TUNを有効にすれば必ず解決するわけではありません。OSの権限、ルート、クライアントとコアの対応状況、選択ノードのUDP対応を個別に確認してください。

会議がつながるのに映像や音声が不安定な場合は、まず接続履歴でZoom関連の接続先と通信方式を確認します。ドメインルールに一致しているか、ポリシーが意図したグループか、選択ノードがオンラインかを順に見ます。プロキシ経由の遅延が大きい場合は、別の利用可能なノードと比較してください。ノードを変更するときは他の設定を同時に変えず、同じ会議テストで差を確認すると原因を絞り込みやすくなります。

• Zoomがサインインできない：接続履歴で該当ドメインがどのルールに一致したかを確認します。認証画面だけ直結し、APIが別経路になる場合もあるため、無関係なドメイン全体を一括で追加する前に接続先を調べてください。
• Slackのメッセージ送信や更新が遅い：Slack本体のドメインだけでなく、実際に接続履歴へ現れるAPIやファイル関連の接続先を確認します。確認できたホストだけを追加し、広い範囲のCDNドメインを推測で振り分けるのは避けます。
• ルールは一致するが接続できない：グループで選択中のノード、認証情報、サーバー状態、DNSの結果を確認します。ルール判定が正しくても、選択先のノードに接続できなければアプリは通信できません。
• 国内サイトまで遅くなった：追加したルールが広すぎないか、既存の国内直結ルールより先に意図しない条件へ一致していないかを確認します。追加した行を一時的に外し、変更前の経路に戻るか比較してください。
• 会議後に設定を戻す：一時的に有効にしたTUN、システムプロキシ、モード変更があれば、普段の設定へ戻します。設定を戻した後も接続が不安定な場合は、アプリを再起動し、Clashの接続履歴とOSのネットワーク状態を再確認してください。

会議の安定性は、ドメインルールだけでなく、プロキシノードの遅延と混雑、UDP対応、ネットワークの品質にも左右されます。業務時間中に広範囲のルールやDNS設定を一度に変更せず、1つずつ試して記録を残すと、会議への影響を抑えながら運用できます。クライアントをまだ導入していない場合は、利用するOSに合った配布物を確認してください。