在宅ワークのZoom・Slackを快適にするClashのルール設定術

在宅ワークの通信を「会議・チャット・社内接続」に分ける

ZoomやSlackの接続が不安定なとき、まず考えたいのは、すべての通信を同じ出口へ送ることではなく、仕事に必要な通信だけを適切な経路へ振り分けることです。Clashのルールは、コアに届いた接続を宛先などの条件で判定し、DIRECTまたはプロキシポリシーへ送ります。クライアントでシステムプロキシを有効にしただけでは、システムプロキシを利用しないアプリや、Clashに取り込まれていない通信まで自動的に振り分けられるわけではありません。

仕事用の基本方針は、社内ネットワークや社内サービスをDIRECT、必要な会議・チャットサービスを仕事用プロキシ、その他の通信を既存の標準ルールに任せる形です。社内VPNや会社指定の接続方法がある場合は、先に管理者の指示を確認してください。Clashのルールを追加しても、会社のアクセス制御や認証要件を回避できるわけではありません。

通信の種類	基本の経路	確認するポイント
Zoomの会議・チャット	接続先に応じて仕事用プロキシを検討	ログ上のドメインと実際の会議品質を両方確認します。音声・映像のUDP通信が同じ経路を通るとは限りません。
Slackのメッセージ・ファイル	必要なドメインだけ仕事用プロキシへ	ファイルや画像の取得先が別ドメインになる場合があります。接続ログで利用中の通信を確認します。
Google Meet	会議に必要な通信を確認して選択	Googleの他サービスまで一括して振り分けないよう、対象を限定してテストします。
社内ポータル・LAN機器	`DIRECT`または会社指定の経路	社内DNS、社内VPN、プライベートIPへの経路が維持されているか確認します。

システムプロキシとTUN、DIRECTとプロキシの役割を整理する

経路設定を始める前に、どの通信がClashに届いているかを切り分けます。システムプロキシは、OSのプロキシ設定を参照するアプリのHTTP・HTTPS通信などをローカルのプロキシポートへ送ります。アプリ独自のプロキシ設定、直接接続、UDP通信などは、システムプロキシだけでは取り込まれないことがあります。TUNは仮想ネットワークインターフェースを使って対象のIP通信を取り込みますが、DNS、ルート、除外設定などの影響を受け、すべての通信が必ず同じように処理されるとは限りません。

Zoom会議では、会議参加後に映像が止まる、音声だけ途切れるといった症状が出ることがあります。Webページが開けることだけで会議経路も正常だと判断せず、接続画面で該当する通信が見えるかを確認します。UDPのメディア通信がコアに取り込まれていない場合、ドメインルールを追加してもその通信の経路は変わりません。まずシステムプロキシかTUNのどちらを使用しているか、クライアントとコアがその通信方式に対応しているかを確認してください。

Ruleモードではルールとポリシーの両方を見る

普段の振り分けにはRuleモードを使います。ルールは上から順に照合され、最初に一致した行のポリシーが使われます。ルールが「仕事用プロキシ」を指定していても、ポリシーグループ内でDIRECTが選択されていれば、実際の出口は直接接続になります。設定ファイルだけでなく、クライアントのプロキシ画面で選択中のポリシーも確認しましょう。

Globalモードは、ルールを通さず選択中のGLOBALポリシーで一時的に動作を比較する用途に向いています。特定サービスがRuleで失敗し、Globalで成功した場合は、ルールの一致先やグループの選択を調べる手掛かりになります。ただし、Globalに切り替えてもClashに取り込まれていないアプリ通信が自動で取り込まれるわけではありません。調査が終わったらRuleへ戻し、通常の分流に復帰してください。

仕事用ルールを追加して動作を確認する

次の例は、既存設定に統合するルール部分のサンプルです。仕事用プロキシは例示のポリシー名なので、実際の設定に存在するグループ名へ置き換えてください。グループがなければ、既存の適切なプロキシグループを指定します。サブスクリプション設定全体を置き換える例ではありません。

rules:
  - DOMAIN-SUFFIX,zoom.us,仕事用プロキシ
  - DOMAIN-SUFFIX,zoom.com,仕事用プロキシ
  - DOMAIN-SUFFIX,slack.com,仕事用プロキシ
  - DOMAIN-SUFFIX,slack-edge.com,仕事用プロキシ
  - DOMAIN-SUFFIX,slack-files.com,仕事用プロキシ
  - DOMAIN,meet.google.com,仕事用プロキシ
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,既存の標準ポリシー

この例のプライベートIP範囲は一般的な社内LANの例です。会社のネットワークが別のアドレス範囲を使っている場合や、社内サービスがホスト名で提供されている場合は、その環境に合わせて調整してください。社内接続に専用のVPNやDNSが必要なら、単に広いIP範囲をDIRECTへ送るだけでは不十分な場合があります。会社のネットワーク要件を確認し、不明な範囲を推測で追加しないでください。

現在の設定を保管：Profiles（プロファイル）で使用中の設定を確認し、編集前にコピーまたはバックアップを作成します。サブスクリプション更新で直接編集が上書きされることがあるため、対応するMixinやオーバーライド機能があれば、クライアントの仕様に沿って利用してください。
ポリシー名とルール順を確認：例のポリシー名が実際のグループと一致することを確認します。追加するサービスルールは、広い条件や末尾のMATCHより前に配置します。特にMATCHを先頭へ移すと、後続の個別ルールが照合されません。
一度に少数のルールを追加：最初はZoomなど対象を一つに絞り、設定を再読み込みします。複数サービスのドメインを一度に追加すると、問題が起きた際に原因を特定しにくくなります。
接続ログで照合結果を確認：会議参加やSlackへのサインインなど、新しい接続を発生させ、Connections（接続）またはLogs（ログ）で宛先、ルール、ポリシーを確認します。既存の接続はルール変更後もそのまま残ることがあるため、アプリを再接続して比較してください。
会議と社内サービスを実地確認：短いテスト会議で音声・映像・画面共有を確認し、Slackのメッセージとファイル、社内ポータル、プリンターなども個別に試します。正常なら次のサービスへ進みます。

会議の遅延やSlackの不調を症状別に切り分ける

接続が不安定なときは、まず症状を分けます。Zoomのログイン画面は開くのに会議の音声が途切れる場合、ブラウザー経由の通信と会議メディアの通信で取り込み方が異なる可能性があります。Slackでメッセージは送れるのにファイルだけ失敗する場合は、ファイル取得先の接続が別ルールに一致していない可能性があります。アプリ全体を一律にGlobalへ送る前に、失敗した操作の時刻に新しい接続が記録されているかを確認してください。

症状	優先して確認する項目	次の確認
会議画面は開くが音声・映像が不安定	会議中の接続ログ、UDP通信の取り込み、TUNの状態	クライアントのサポート範囲と会議アプリのネットワーク設定を確認し、別の出口で短時間比較します。
Slackの画像やファイルだけ取得できない	失敗時に記録された接続先ドメインと適用ルール	実際の接続先を特定し、必要なドメインルールだけを追加して再接続します。
社内サイトやプリンターに届かない	社内DNS、ローカルIP範囲、会社指定VPNとの競合	会社のネットワーク要件を確認し、対象サービスの名前解決と経路を分けて試します。
ルール変更後も結果が変わらない	接続がClashに取り込まれているか、古い接続が残っていないか	アプリを再接続し、新しい接続のルール一致先と実際のポリシーを確認します。

ノード選びでは、遅延の表示だけで判断しないことも大切です。ヘルスチェックの応答時間が小さくても、会議サービスへの接続品質や混雑状況が同じとは限りません。仕事用に使う候補を少数に絞り、同じ時間帯に音声、映像、画面共有を試して比較します。頻繁に出口を切り替えると会議が再接続になる場合があるため、会議中の自動切り替えやノード変更は慎重に行ってください。

問題の切り分けが終わったら、通常のRuleモードと普段のポリシー選択に戻し、設定のバックアップも更新します。Clash for Windowsは開発・保守が終了しているため、使用中のクライアントとコアの対応状況を確認し、別のクライアントへ移行する場合は設定項目の互換性を個別に確かめてください。