この記事で分かること
在宅勤務では、ブラウザでニュースを読むだけなら問題がないのに、Zoom の会議が数分おきに止まる、Slack の通知が遅れて届く、Google Meet の音声だけが不安定になるといった症状が起きることがあります。原因は回線速度そのものとは限りません。業務サービスごとに接続先や通信方式が異なり、すべての通信を同じプロキシへ送った結果、国内向けサービスまで遠回りしているケースもあります。
本稿では、Clash 系クライアントを在宅勤務で使うことを前提に、Zoom・Slack・Google Meet を必要に応じてプロキシへ振り分け、国内サイトや社内リソースは DIRECT に残すための考え方を整理します。Clash Verge Rev や Mihomo 系クライアントで共通するルール分流、システムプロキシと TUN の使い分け、DNS の注意点、ログを使った確認方法まで、家庭の Wi-Fi と会社の VPN が混在する環境を想定して説明します。
なお、会社支給端末や社内ネットワークでは、許可されていないプロキシや TUN の利用が規程違反になる場合があります。業務データを扱う端末では、まず勤務先の情報セキュリティポリシーを確認し、会社指定の VPN・プロキシがある場合はそちらを優先してください。
在宅勤務で最初に決める通信方針
Clash の設定で最初から「すべて PROXY」にすると簡単に見えますが、ビデオ会議と業務サイトを同じ経路に押し込むと、かえって遅延や切断が増えることがあります。重要なのは、サービス名だけで判断せず、通信の目的、接続先、必要な経路を分けて考えることです。
たとえば、会社のポータル、勤怠システム、国内のクラウドストレージが通常の回線で問題なく開けるなら、これらは DIRECT のままにできます。一方、契約しているネットワーク環境で海外の SaaS や特定の認証サーバーへ到達しにくい場合は、該当ドメインだけを PROXY に送ります。Zoom や Meet は会議サーバー、認証、設定取得、メディア中継など複数の接続先を使うため、一つのドメインだけを登録すれば必ず安定するとは限りません。
| 用途 | 基本方針 | 確認したい症状 |
|---|---|---|
| Zoom の会議音声・映像 | まず DIRECT と PROXY を個別に比較する | 音声の途切れ、映像の解像度低下、再接続 |
| Slack のメッセージ | ワークスペースと関連 API の経路を統一する | 通知遅延、画像やファイルの読み込み失敗 |
| Google Meet | 認証と会議接続を分断しない | 参加失敗、マイク切断、画面共有停止 |
| 国内の社内サイト | 原則 DIRECT。ただし会社指定経路がある場合は従う | ログインループ、社内 DNS の解決失敗 |
特にビデオ会議では、速度テストの数値だけで判断しないことが大切です。下り速度が十分でも、経路の往復遅延、パケットロス、UDP の扱い、短時間の経路変更によって会話が不自然に遅れることがあります。会議中に相手の声が一瞬消える場合は、単純な帯域不足ではなく、プロキシ経由による遅延や UDP から TCP への切り替えが関係している可能性もあります。
Zoom・Slack・Meet のルールを組み立てる
Clash のルールは上から順番に評価されるため、広いルールを先に置くと、後から追加した個別ルールに到達しません。まず業務上必ず DIRECT にしたい社内ドメインやローカルネットワークを上に置き、その次にプロキシへ送るサービス群、最後に一般通信を受ける MATCH を置く構成が扱いやすいです。
代表的な設定例は次のようになります。実際のホスト名やポリシーグループ名は、使用しているプロファイルと契約先に合わせて置き換えてください。サービスの接続先は更新されることがあるため、以下を完全な一覧ではなく、ログ調査を始めるためのたたき台として利用します。
rules:
- DOMAIN-SUFFIX,company.example,DIRECT
- DOMAIN-SUFFIX,zoom.us,MEETING
- DOMAIN-SUFFIX,zoom.com,MEETING
- DOMAIN-SUFFIX,slack.com,WORK
- DOMAIN-SUFFIX,slack-edge.com,WORK
- DOMAIN-SUFFIX,google.com,WORK
- DOMAIN-SUFFIX,meet.google.com,MEETING
- MATCH,DIRECTZoom では、アプリのログインや会議情報の取得と、実際の音声・映像通信が同じ接続先とは限りません。zoom.us だけを PROXY にしても、会議中のメディア経路が別のホストへ向かえば、その通信は MATCH の処理へ落ちます。会議を開始した直後に Clash の接続ログを開き、接続先、使用ルール、プロキシグループ、エラーの有無を確認してください。
Slack も、メッセージ本文、ファイル、画像、通知用の長時間接続でホストが分かれることがあります。通知だけ遅れる場合は、アプリ全体の再起動を繰り返すより、Slack のワークスペースに接続している長時間接続がどの経路を通っているかを確認する方が有効です。認証ページだけ PROXY、API は DIRECT のように分かれていると、ログインはできても新着メッセージの反映が遅れることがあります。
Google Meet では Google アカウントの認証、会議ページ、音声・映像の中継が関係します。Google 全体を無条件に PROXY へ送ると、検索や国内サービスまで遠回りになるため、最初は会議に必要な接続だけをログで特定します。企業アカウントを使う場合は、管理者が指定するログイン先やセキュリティ製品のドメインを勝手に除外しないでください。
Clash で実際に設定して検証する手順
ここでは、Clash Verge Rev などの GUI クライアントを使い、既存プロファイルを壊さずに段階的に確認します。設定前に現在のプロファイルを複製するか、購読更新で上書きされない専用のオーバーライド欄を使ってください。購読ファイルを直接編集すると、次回更新時に変更が消えることがあります。
- プロキシグループを確認する。会議用、業務用、通常通信など、目的に合うグループを用意します。最初は自動選択よりも、安定性を比較しやすい固定ノードを一時的に選ぶと原因を追いやすくなります。
- システムプロキシを有効にする。ブラウザや多くのデスクトップアプリが設定を読み取れる状態にします。切り替え後はブラウザだけでなく、Slack や Zoom もいったん終了してから起動し直します。
- ルールを追加する。社内ドメインとローカルネットワークを DIRECT、必要な Zoom・Slack・Meet の接続先を目的別グループへ振り分け、最後に MATCH を置きます。
- 会議を短時間テストする。Zoom、Slack 通話、Google Meet をそれぞれ数分ずつ使い、音声の遅延、画面共有、ファイル送信、通知の到着を記録します。同じ Wi-Fi で DIRECT と PROXY を比較すると差が見えやすくなります。
- ログでルールを確定する。失敗した時刻のログを確認し、DIRECT に落ちた必要ホストや、意図せず PROXY へ送られた国内ホストを修正します。修正後は一度に多くの変更を加えず、サービスごとに再テストしてください。
システムプロキシを設定してもアプリだけが直結する場合は、アプリが OS のプロキシ設定を読んでいない可能性があります。その場合に TUN を試す方法がありますが、いきなり常用するのは避けてください。TUN はプロキシ環境変数を無視するプロセスも捕捉しやすい反面、会社 VPN、ウイルス対策ソフト、Docker、仮想マシン、IPv6 と競合することがあります。TUN を有効にする前に、既存 VPN を停止できるか、管理者権限があるか、社内規程に違反しないかを確認します。
設定変更後に会議が急に不安定になった場合は、ノードを替える前に切り分けを戻します。まず Clash を停止して通常回線で試し、次にシステムプロキシだけ、最後に TUN という順序で比較します。どの段階で症状が変わったかを記録すれば、ノード品質、ルール、アプリのプロキシ対応、VPN 競合のどこに問題があるかを絞り込めます。
DNS・通知遅延・会議切断を減らす運用
ドメインルールが正しくても、DNS の応答が不安定だと、接続先の選択や到達性で問題が起きます。Clash の DNS 機能を使う場合は、ローカルネットワークや会社内の名前解決を壊さないことが優先です。社内ホストが内部 DNS でしか解決できない環境では、すべての DNS を外部へ送る設定にせず、社内ドメインを指定 DNS に分ける必要があります。
また、Zoom や Meet の音声は、映像よりも小さな遅延やパケットロスの影響を受けやすい通信です。高負荷のノードへ会議と大容量ダウンロードを同時に流すと、会議が途切れやすくなります。会議中は動画の大量アップロード、クラウド同期、OS の大型更新を一時停止し、同じプロキシグループを使う端末数も確認してください。ノードの帯域だけでなく、同時接続数や混雑時間帯も結果に影響します。
Slack の通知が遅れるときは、スマートフォンと PC の両方を同じプロキシへ接続したことで、バックグラウンド通信が制限されていないかも見ます。モバイル OS の省電力設定、社内 VPN の常時接続、アプリの通知権限は Clash の外側にあるため、ルールだけを変更しても改善しないことがあります。PC では通知が届くがスマートフォンだけ遅い場合、端末ごとに DNS、VPN、バックグラウンド制限を別々に確認してください。
設定を安定させるには、変更内容を簡単に記録する習慣も役立ちます。「7 月 25 日、Meet の認証を WORK、会議接続を MEETING に変更」「DIRECT では音声が途切れ、固定ノードでは改善」のように、日時と結果を残します。購読更新後に挙動が変わっても、どの設定が自分で追加したものかをすぐに判断できます。
よくある失敗と安全な戻し方
ブラウザは安定するのに Zoom だけ止まる場合、ブラウザのシステムプロキシと Zoom の通信経路が異なっている可能性があります。Zoom の設定にプロキシ項目がある場合は組織の指示に従い、Clash のログに接続が現れるかを確認します。ログに何も出ないなら、システムプロキシではなく TUN、またはアプリ側の専用ネットワーク処理が必要になることがあります。
Slack の通知は届くがファイルだけ開けない場合は、ファイル配信用の CDN や別ホストがルールから漏れている可能性があります。ファイルの URL をそのまま無差別に登録するのではなく、ログでホスト名を確認し、ワークスペースの認証経路と同じポリシーで試してください。
Meet に入れるがマイクや画面共有が使えない場合は、Clash だけでなく OS のプライバシー権限、ブラウザのサイト権限、会社のセキュリティソフトも確認します。通信経路を変えた直後はブラウザを再起動し、マイク入力とカメラの許可状態を再確認します。
最も危険なのは、原因が分からないままルールを増やし続けることです。設定が複雑になったら、プロファイルをバックアップしたうえで追加ルールを一時的に無効化し、最小構成へ戻します。DIRECT、単一プロキシ、TUN の順に比較し、症状が再現する条件を一つずつ確認すれば、元の環境へ安全に戻しながら改善できます。
在宅勤務向けの専用 VPN アプリは、設定項目が少なく始めやすい一方、Zoom の会議だけを別経路にする、Slack の認証とファイル配信を同じグループへそろえる、国内サイトを確実に直結する、といった細かな調整が難しいことがあります。Clash はルール、ログ、システムプロキシ、TUN を段階的に選べるため、通信先ごとの挙動を確認しながら自分の勤務環境に合わせて調整できます。必要な通信だけをプロキシへ送り、不要な遠回りを減らしたい方は、対応するクライアントをダウンロードして今回の手順を小さなテストから試してみてください。