リモートワークのClash設定術｜Zoom・Slack・Meetを快適に使う方法

リモートワーク向け設定の考え方

在宅勤務でZoom、Slack、Google Meetなどを使う場合、端末上のすべての通信を常に同じプロキシへ送れば快適になるとは限りません。業務サービスは安定した経路が必要ですが、社内ファイルサーバー、プリンター、家庭内NAS、ルーター管理画面までプロキシへ送ると、接続できなくなったり、遅延が増えたりします。Clashでは「仕事用サービスだけをプロキシへ振り分け、それ以外は用途に応じて直接接続する」という設計が扱いやすい方法です。

ただし、ZoomやSlackの通信先は固定された1つのドメインだけではありません。ログイン、API、画像配信、音声・映像の中継、アップデートなどで複数のホスト名やCDNが使われます。そのため、最初から少数のドメインを決め打ちするのではなく、まずアプリの通信を確認し、必要なドメインをルールへ追加する手順が安全です。会社が指定するネットワーク、認証方式、データ保護ポリシーがある場合は、Clashの設定よりも社内の指示を優先してください。

会議用ノードと業務用グループを分ける

Clashのルールは、通信をどの出口へ送るかを指定します。ここで直接ノード名を書くこともできますが、会議用、業務用、通常用のように策略グループを作っておくと、障害時に画面から切り替えられます。Zoomの会議用通信には低遅延のノード、SlackやMeet以外の業務サービスには安定性を重視したノードというように、用途ごとに選択基準を変えることができます。

url-testは定期的に遅延を測定して自動選択するグループですが、測定値が低いノードが実際の会議品質でも最良とは限りません。ICMPやHTTPの応答が速くても、UDPの品質、混雑時間帯、映像中継サーバーまでの経路が不安定な場合があります。会議では自動切り替えより、まず手動選択で数回テストし、必要に応じて予備ノードへ切り替える運用が向いています。

proxy-groups:
  - name: WORK-MEETING
    type: select
    proxies:
      - Meeting-JP-1
      - Meeting-SG-1
      - DIRECT

  - name: WORK-CHAT
    type: select
    proxies:
      - Stable-JP-1
      - Stable-SG-1
      - DIRECT

  - name: PROXY
    type: select
    proxies:
      - WORK-MEETING
      - WORK-CHAT
      - DIRECT

上の例では、WORK-MEETINGとWORK-CHATを別々に操作できます。実際のノード名は契約しているサービスの構成に合わせて置き換えてください。ノード名に日本語や記号が含まれている場合は、インデントと文字列を崩さないよう、クライアントが生成した名前をそのまま使うのが安全です。

ドメインルールを作るときの注意点

ドメイン単位の振り分けでは、完全一致のDOMAINより、サブドメインもまとめて対象にできるDOMAIN-SUFFIXをよく使います。ただし、サービスのドメインを広く指定しすぎると、業務通信以外の配信や広告まで同じグループへ送られることがあります。公式ドキュメントや実際の接続ログを確認し、必要な範囲だけを登録してください。

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,meet.google.com,WORK-MEETING
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - MATCH,PROXY

この例は出発点であり、すべての環境で完全な一覧になるわけではありません。特にGoogle系サービスは、Meet本体以外の認証やAPIに別のホスト名を使うことがあります。google.comを広くプロキシへ送ると、個人のGoogleサービス全体が対象になるため、会社の運用方針と通信量を確認してから採用してください。

実践手順:ログを見ながら設定する

ここでは、WindowsやmacOSのClash Verge系クライアント、またはmihomoを搭載したクライアントを想定します。画面上の名称はバージョンによって異なりますが、作業の順番は共通です。最初からTUNを有効にして全通信を取り込むより、通常のシステムプロキシでドメインとノードを確認してからTUNへ進む方が、原因を切り分けやすくなります。

1. サブスクリプションを更新し、利用可能なノードの中から、会議に使う候補を2つ以上選びます。極端に遠い地域や、遅延が大きく変動するノードは候補から外します。
2. 策略グループを作成または編集し、会議用グループには候補ノードだけを登録します。会議中の自動切り替えを避けるため、最初はselectを使用します。
3. システムプロキシを有効にし、Clashの接続ログを開いた状態でZoom、Slack、Meetを順番に起動します。ログには実際に接続されたホスト名、ポート、使用された策略グループが表示されます。
4. ログから業務サービスに必要なドメインを確認し、DOMAIN-SUFFIXまたはDOMAINルールを追加します。ログイン用、API用、ファイル配信用など、用途が異なるホストを一括で決めつけないでください。
5. 一度アプリを完全終了してから再起動し、ログイン、メッセージ送信、ファイル共有、会議参加を個別にテストします。各通信が意図したグループへ入っているかを確認します。
6. 必要な通信がシステムプロキシを迂回している場合だけ、TUNモードを有効にします。管理者権限、VPN構成、ネットワーク拡張などのOS許可が表示されたら、内容を確認して許可します。

テスト時は、会議へ接続したままノードを交換しないでください。まず5分ほど音声だけで遅延や途切れを確認し、その後カメラをオンにして映像の品質を確認します。Slackではメッセージ、スレッド、ファイルのアップロードとダウンロードを別々に試します。Meetではブラウザのマイク・カメラ権限と、ブラウザ内蔵のセキュアDNS設定も確認対象になります。

TUNモードとDNSを業務通信に合わせて調整する

システムプロキシは、HTTPやHTTPSの設定を参照するアプリを中心に制御します。一方、会議アプリやブラウザのWebRTC、独自のネットワーク処理はシステムプロキシを迂回することがあります。端末全体を同じルールで扱いたい場合は、mihomoのTUNモードが有効です。TUNは仮想ネットワークインターフェースでIP通信を取り込み、UDPを含むアプリの通信をClashへ渡します。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.example.invalid/dns-query
  proxy-server-nameserver:
    - https://dns.example.invalid/dns-query

上記のexample.invalidは説明用の無効な値です。実際には、利用環境で接続可能なDNSサーバーへ置き換えてください。dns-hijackは端末から出るDNS問い合わせをClashへ取り込み、fake-ipはドメインとルールの対応を維持しやすくします。ただし、社内VPN、オンラインゲーム、プリンターなどがfake-ipと互換性を持たない場合があります。その場合は対象ドメインをfake-ip-filterへ追加するか、問題のアプリだけTUN対象から外すなど、範囲を限定して調整します。

DNSを変更しても、ZoomやMeetの品質が必ず改善するわけではありません。DNSは主に接続先の名前解決とルール判定に関わり、会議中の映像品質はノードまでの遅延、UDPの到達性、帯域、混雑、端末のWi-Fi品質に大きく左右されます。したがって、DNS設定を変更した後は、名前解決の成功だけでなく、実際の会議接続と音声・映像の状態を確認してください。

会議品質を数値とログで確認する

「ページが開く」だけでは業務用として十分とは言えません。Clashの接続ログで会議関連の通信が意図したグループへ入っていることを確認し、会議アプリ側の統計画面で遅延、ジッター、パケット損失を記録します。映像を低画質にしてもパケット損失が高い場合は、ルールよりノードやWi-Fiが原因である可能性が高くなります。逆に特定の機能だけ失敗する場合は、未登録のドメイン、ブラウザの直接接続、UDPを処理しない経路を疑います。

接続が不安定なときの切り分け

トラブルが起きたら、設定を一度に何箇所も変更せず、通信範囲、ルール、ノード、DNSの順番で確認します。最初にClashを一時停止し、同じネットワークで会議が正常に動くかを確認します。Clashを停止しても不安定なら、Wi-Fi、回線、会社VPN、アプリ側の障害を先に調べるべきです。

• Slackだけ接続できない。ワークスペースのドメイン、認証用ホスト、ファイル配信先が別々の経路になっていないか確認します。ブラウザ版とデスクトップ版で接続先が異なることもあります。
• Zoomは参加できるが音声が途切れる。TCP接続だけでなくUDPの経路を確認し、混雑しているノードを避けます。ノードを変えて改善するなら、ルールより出口品質の問題です。
• Meetでカメラや画面共有だけ失敗する。ブラウザの権限、WebRTC、TUNのUDP取り込み、セキュリティソフトの遮断を順に確認します。
• 社内サイトだけ開けない。社内ドメインとプライベートIP帯をDIRECTへ送るルールを確認します。社内DNSが必要な環境では、ClashのDNSへ無条件に置き換えないでください。
• 設定変更後に何も通信できない。YAMLのインデント、策略グループ名、ノード名、未対応フィールドを確認し、クライアントの設定検証機能でエラー箇所を特定します。

最終的には、会議用グループを手動選択、業務サービスのルールを明示、LANと社内経路をDIRECT、残りを既存のフォールバックへ送る構成が管理しやすい形です。設定ファイルを変更する前にバックアップを保存し、業務時間外にテストしてください。サブスクリプションの更新でルールやノードが置き換わる場合もあるため、月に一度はログと会議品質を再確認すると、突然の接続障害を見つけやすくなります。