在宅勤務のClash設定術｜Zoom・Slack・Meetを快適に使う分流ガイド

在宅勤務の通信を「会議・業務・日常」に分ける

在宅勤務でClashを使うときは、すべての通信を同じノードへ送るのではなく、用途ごとに経路を分けることが重要です。Zoom、Slack、Google Meetは、画面表示だけでなく、音声、映像、ファイル転送、WebSocket、通知など複数の通信を使います。一方、普段利用する国内のニュース、銀行、通販、動画配信、社内ポータルまで常に遠いプロキシを経由すると、ページ表示が遅くなったり、ログイン確認が増えたりすることがあります。

基本方針は、会議サービスは安定した専用グループ、業務チャットは用途に合うプロキシまたは自動選択、国内サービスはDIRECT、判定できない通信は最後のMATCHという構成です。ここでいうDIRECTはプロキシを使わず、現在接続している自宅回線や会社のネットワークから直接アクセスする動作を指します。通信を分流しても、会議サービス側の障害、Wi-Fiの混雑、上り帯域の不足まで解決できるわけではありません。まずネットワーク自体が安定していることを確認してください。

Zoom・Slack・Meetのルールを組み立てる

ルールは上から順に照合されるため、会議サービス用のルールを一般的な海外ルールやMATCHより前に置きます。サービスのドメインは変更・追加されることがあるため、1つのホスト名だけを登録して「すべての通信を捕捉できた」と判断しないでください。特に会議では、ログイン用のWebページ、会議制御、音声・映像のメディア、補助APIが別々のドメインや接続先IPを使うことがあります。

次は構造を理解するための簡略例です。実際の設定では、使用しているサブスクリプションのプロキシグループ名に合わせて WORK-MEETING や WORK-CHAT を置き換えてください。グループ名に日本語を使うこともできますが、YAMLの記号やインデントを崩さないようにします。

proxy-groups:
  - name: WORK-MEETING
    type: url-test
    include-all: true
    filter: "(?i)東京|大阪|JP|低遅延"
    url: https://www.gstatic.com/generate_204
    interval: 300

  - name: WORK-CHAT
    type: url-test
    include-all: true
    filter: "(?i)JP|Singapore|低遅延"
    url: https://www.gstatic.com/generate_204
    interval: 300

rules:
  - DOMAIN-SUFFIX,zoom.us,WORK-MEETING
  - DOMAIN-SUFFIX,zoom.com,WORK-MEETING
  - DOMAIN-SUFFIX,slack.com,WORK-CHAT
  - DOMAIN-SUFFIX,slack-edge.com,WORK-CHAT
  - DOMAIN-SUFFIX,google.com,WORK-MEETING
  - DOMAIN-SUFFIX,googleapis.com,WORK-MEETING
  - DOMAIN-SUFFIX,gstatic.com,WORK-MEETING
  - GEOIP,JP,DIRECT
  - MATCH,PROXY

DOMAIN-SUFFIXは対象ドメインとそのサブドメインをまとめて指定する記法です。ただし、Google Meetの通信を google.com だけで完全に表せるとは限りません。広すぎるドメイン指定は、Meetとは無関係なGoogleサービスまで同じ経路へ送る可能性があります。ルールプロバイダーを利用できる環境では、定期更新される業務サービス用ルールセットを使い、更新日時と取得失敗のログも確認するほうが安全です。

会議の映像通信は遅延だけで選ばない

ZoomやMeetでは、Webページの読み込みが速いノードでも、長時間の音声・映像通信が安定するとは限りません。会議の品質には往復遅延、パケットロス、ジッター、上り方向の帯域が影響します。HTTPのURLテストが 60 ms でも、映像中にパケットロスが増えれば、相手の声がロボットのように聞こえたり、カメラ映像が低画質へ切り替わったりします。

• 低遅延グループ：近い地域のノードを中心にし、会議開始前に遅延と接続状態を確認します。
• 安定性グループ：少し遅くても、30分から60分の連続接続で切断されにくいノードを優先します。
• 予備ノード：自動選択だけに任せず、手動で切り替えられる候補を2つ以上残します。
• UDP対応：UDP経由のメディアを使う場合、回線やノードがUDPを安定して通せるかを確認します。

FlClashで実際に分流を設定する手順

ここでは、現在の設定を壊さずに試すための手順を説明します。FlClash、Clash Verge Rev、Mihomo系クライアントでは画面名が少し異なる場合がありますが、プロファイル、プロキシグループ、ルール、システムプロキシまたはTUNという順番で確認すると迷いにくくなります。

1. 現在のプロファイルを複製する：購読設定を直接編集せず、ローカルのオーバーライドまたは複製したプロファイルで作業します。更新後に元の購読内容で上書きされない場所へ保存してください。
2. 会議用グループを作る：プロキシ画面で、近い地域のノードを2～5個選びます。名前が似ていても、同じサーバーや同じ回線系統に偏らないようにします。
3. ルールを追加する：Zoom、Slack、Meetのドメインルールを、一般ルールと MATCH より上に配置します。グループ名のスペルが実際のプロキシグループと一致しているか確認します。
4. まずシステムプロキシで試す：ブラウザーや対応アプリだけを対象にする場合は、システムプロキシを有効にします。ローカルの混合ポートは例として 127.0.0.1:7890 が使われますが、実際の値は設定の mixed-port を確認してください。
5. 必要な場合だけTUNを有効にする：会議アプリがシステムプロキシを無視する場合はTUNを検討します。管理者権限、VPNプロファイル、DNSの引き受け、他のVPNソフトとの競合を順番に確認してください。
6. 会議前にテストする：Zoomのテストミーティング、Slackのメッセージ送信とファイル取得、Meetのマイク・カメラ確認を別々に実施します。

テスト中は、クライアントの接続一覧で実際のドメインと適用された策略を確認します。設定したはずのルールが使われていない場合、原因はドメイン不足だけとは限りません。DNSモードによって接続先がIPとして表示されること、既存ルールが先に一致していること、アプリが独自のQUICやDoH接続を使っていることもあります。ルールを増やす前に、接続ログで失敗したホスト名、ポート、プロトコルを記録してください。

会議品質を確認し、問題が出たときに戻す

ノード選択では、単発の速度テストより実際の利用時間を重視します。午前と午後で混雑が変わることがあるため、同じ会議用ノードを数回使い、音声の途切れ、映像の停止、再接続の有無を記録します。ZoomやMeetの統計画面で遅延、ジッター、パケットロスを確認できる場合は、ノードを替える前後で比較してください。数値が悪化したときに、すぐルール全体を変更するのではなく、会議用グループだけを切り替えると原因を追いやすくなります。

仕事が終わった後もTUNやシステムプロキシを常時有効にするかは、利用環境に合わせて決めます。常時有効にする場合は、国内サービス、社内ドメイン、プリンターやNASなどのローカルネットワークを誤って遠いノードへ送らないようにします。逆に、会議中だけClashを有効にする運用なら、開始前にプロファイル、グループ選択、システムプロキシの状態を確認するチェックリストを作ると、設定忘れを減らせます。

最後に、会議サービスのドメインを無制限に追加することは避けてください。広すぎるルールはプライバシー、速度、社内アクセスの予測可能性を損ねます。まずは必要なサービスだけを対象にし、ログと会議品質を見ながら段階的に調整するのが安全です。FlClashの対応プラットフォームとインストール方法を確認する場合は、ダウンロードを確認してください。