この記事で分かること
在宅勤務では、Zoom や Google Meet の映像・音声を安定させながら、Slack、社内ポータル、国内向けの業務サービスは普段どおり使いたい場面が多くあります。そこで役立つのが、通信先やドメインに応じて経路を分ける Clash のルール分流です。海外向け通信をプロキシ経由にし、国内サイトや社内 LAN は DIRECT にすることで、すべての通信を一律に迂回させずに済みます。
この記事では、Clash Verge Rev などのデスクトップ版クライアントと Mihomo 系コアを想定し、ルールの考え方、会議用ノードの選び方、設定の確認方法、トラブル時の切り分けを順に説明します。Zoom や Slack の接続先はアプリの機能や更新によって変わることがあるため、固定のドメイン一覧をそのまま適用するのではなく、利用環境のログを確認して調整する方法を中心に紹介します。
在宅勤務で通信を分ける理由
Clash のルールモードでは、通信先のドメインや IP アドレスなどに条件を付け、指定したポリシーへ振り分けます。たとえば、社内システムや国内の業務サイトは DIRECT、プロキシ経由にしたい外部サービスは利用中のプロキシグループへ送る、といった形です。全通信をプロキシに送るグローバルモードと異なり、必要な通信だけを切り替えられるため、社内 VPN、プリンター、ファイル共有などとの共存を検討しやすくなります。
会議アプリは、映像・音声の送受信だけでなく、ログイン、会議情報の取得、チャット、画面共有、更新確認など複数の通信を行います。そのため「Zoom の画面が開く」ことと「会議が安定する」ことは同じではありません。認証は成功しても、音声が途切れる、画面共有の開始に時間がかかる、Slack の通知だけ遅れるといった場合は、関連する通信が異なる経路に分かれている可能性があります。
ただし、すべての会議通信をプロキシへ送れば改善するとは限りません。経由先の混雑や距離が増えると、遅延が大きくなることもあります。まず現在の回線で会議を試し、問題の出るアプリや機能、発生する時間帯を記録してから、必要なルールだけを追加するのが安全です。勤務先のネットワーク規程や情報セキュリティ方針がある場合は、個人判断で経路を変えず、管理者の案内を優先してください。
Zoom・Meet 向けノードの選び方
会議用ノードは、速度テストの数値だけでなく、実際の通話で安定しているかを基準に選びます。短時間の測定で遅延が低くても、混雑する時間帯にパケット損失が増えたり、長時間接続が切れたりするノードは業務には向きません。まず近い地域の候補を数個に絞り、同じ時間帯・同じ端末・同じ回線で通話を比較してください。
| 確認項目 | 見方 | 業務での判断 |
|---|---|---|
| 遅延 | Clash の遅延テストと会議中の反応を確認する | 画面操作や会話の応答が自然な候補を優先する |
| 安定性 | 10〜20 分程度の通話で音切れや再接続がないか見る | 一時的な高速値より、通話中に変動しにくい候補を選ぶ |
| 上り回線 | 自分の映像・音声・画面共有を有効にして試す | 受信だけでなく、送信時の詰まりも確認する |
| 混雑時間帯 | 実際の勤務時間に複数回テストする | 朝や夕方など、会議が多い時間帯の結果を重視する |
ノード選択画面の「自動」や「URL テスト」は候補を絞る目安であり、Zoom や Meet の通話品質を保証するものではありません。テスト先の応答時間と、会議メディアの経路・混雑状況は一致しない場合があります。重要な会議の直前に初めて設定を変えるのではなく、通常の会議と同じ条件で事前に試し、問題があれば元のノードへ戻せるようにしておきましょう。
デスクトップ版でルールを設定する手順
以下は Clash Verge Rev と Mihomo 系コアを使う場合の一般的な流れです。画面上の名称や設定項目はクライアントのバージョン、読み込んだプロファイル、利用中のコアによって異なります。プロファイルがリモート管理されている場合、画面上で直接編集した内容が更新時に上書きされることもあるため、編集方法を確認してから作業してください。
- 現在の状態を控える：アクティブなプロファイル、モード、選択中のノード、システムプロキシの状態を記録します。設定を変更する前にプロファイルをバックアップするか、複製を作成してください。
- ルールモードにする：モード選択で
Ruleを選びます。Globalになっている場合は、国内サイトまでプロキシへ流れることがあるため、まずルールモードで挙動を確認します。 - 会議用ポリシーを確認する：既存プロファイルにあるプロキシグループの名前を確認します。例の
WORK-PROXYは説明用の名前であり、実際の設定では自分のプロファイルに存在するグループ名へ置き換えてください。存在しない名前をルールに書くと、設定エラーや意図しない経路につながります。 - ログで対象通信を調べる：Zoom、Meet、Slack を起動して実際にログインや会議を行い、接続ログに表示されるホスト名、使用ルール、選択されたポリシーを確認します。対象の通信だけを特定し、アプリの更新通信や無関係な共有サービスまで一括で含めないようにします。
- 小さくルールを追加する：必要なドメインだけを既存ルールに追加し、ポリシーを指定します。ルールは上から評価されるため、広い条件に先に一致してしまわないよう、具体的な条件を適切な位置に置いてください。
- 結果をテストする：会議への参加、マイク・カメラ、画面共有、Slack の送受信を確認します。同時に国内サイト、社内システム、プリンターなども試し、必要な通信が引き続き直接接続されるか確かめます。
ルールを手動で編集できる環境では、次のような記述が基本形になります。これは書式の例であり、実際に追加するホスト名やグループ名を示す完成済みリストではありません。会議アプリの接続先を推測で追加するのではなく、利用中のログや公式のネットワーク要件、組織の管理者から提供された情報を照合してください。
rules:
- DOMAIN,example-meeting-host.example,WORK-PROXY
- DOMAIN-SUFFIX,internal.example,DIRECT
- MATCH,DIRECTMATCH はそれより前のルールに一致しなかった通信を処理するため、最後に置くのが一般的です。プロファイルに既存のルールやグループがある場合は、その構成を壊さないことが重要です。編集後に設定検証でエラーが出たら、インデント、カンマ、グループ名、ルールの順序を見直し、原因を特定できるまでは変更前のプロファイルへ戻してください。
国内サイトを DIRECT に保つ設計
在宅勤務では、会議アプリだけでなく、社内ポータル、勤怠管理、クラウドストレージ、プリンター、NAS などを利用することがあります。これらの接続先を一律にプロキシへ送ると、社内ネットワークへ到達できなくなったり、ログイン認証で追加確認が発生したりする場合があります。社内ドメインや LAN 内の通信は、勤務先の指定に沿って DIRECT にするのが基本です。
ドメイン単位のルールは、サービスが利用するホスト名を把握しているときに扱いやすい方法です。一方、サービスが CDN や複数の共有ドメインを使っていると、単純なドメイン指定だけでは対象を網羅できない場合があります。IP アドレスの変化を前提とするサービスもあるため、古い一覧を長期間使い続けず、問題が起きたときにログと公式情報を照合して見直してください。広いドメインサフィックスを追加すると、同じ基盤を利用する無関係なサービスまで同じ経路に入る可能性があります。
国内サイトの直結を確認するときは、トップページが表示されるかだけでなく、ログイン、検索、ファイルのアップロードなど、普段の作業も試します。DNS の応答先や IPv6 の経路がルールの想定と異なる場合、見た目では原因が分かりにくいことがあります。Clash の接続ログで実際のルールとポリシーを確認し、必要なら管理者にドメインやネットワーク要件を問い合わせてください。
接続が不安定なときの切り分け
会議中の音切れや切断が起きた場合は、すぐにルールを増やすのではなく、問題がどの範囲に及んでいるかを確かめます。Clash を一時停止した状態で症状が変わるか確認する方法もありますが、勤務先の規程に反する操作は避けてください。原因がネットワーク全体なのか、特定のアプリなのか、特定ノードなのかを分けるだけでも、不要な変更を減らせます。
- 会議アプリだけ失敗する：接続ログで認証、会議参加、音声・映像の通信がどのルールに一致したか確認します。ルールに載せたホストが実際の接続先と合っているかも見直します。
- 一部のノードでだけ途切れる：同じ条件で別ノードを試し、時間帯による混雑や長時間接続の安定性を比較します。遅延テストの値だけでなく、通話中の変化を記録してください。
- 国内サイトや社内システムも遅い：広すぎるプロキシルール、ルールの順序、DNS 設定を確認します。直前に変更した箇所を一つずつ元に戻し、挙動が変わるか比較します。
- ブラウザは動くがアプリが失敗する：デスクトップアプリがシステムプロキシに従うか、Clash の TUN が必要かを確認します。TUN は通信を広く取り込める一方、社内 VPN や端末管理ソフトと競合する可能性があるため、必要性と組織の許可を確認してから試します。
在宅勤務では、会議が始まる直前の大幅な設定変更は避けるのが実務的です。変更前のプロファイル、変更日時、テストしたノード、発生した症状を短く記録しておくと、元に戻す判断が簡単になります。特に業務端末では、Clash の設定だけで解決しようとせず、ルーター、Wi-Fi の電波状況、社内 VPN、セキュリティ製品のログも必要に応じて確認してください。
よくある質問
会議アプリの通信をすべてプロキシに送るべきですか？
必ずしもそうではありません。プロキシ経由で改善する場合もありますが、ノードの距離や混雑によって遅延が増えることもあります。まず実際の症状と接続ログを確認し、必要な通信だけを対象に小さく設定して比較してください。勤務先が会議向けのネットワーク要件を定めている場合は、その指示を優先します。
Zoom や Slack のドメイン一覧をそのまま設定できますか？
一覧の内容が現在のアプリ、地域、組織の構成に合っているとは限らないため、そのままの適用はおすすめできません。認証、通話、通知、ファイル共有で異なる接続先が使われることがあります。Clash のログと各サービスの公式情報を照合し、必要なホストだけを追加してください。
システムプロキシを有効にすれば全アプリで使えますか？
いいえ。システムプロキシを利用するアプリもあれば、独自設定を使うアプリや、設定を参照しないアプリもあります。対象アプリが接続ログに現れるかを確認し、現れない場合はアプリ側のプロキシ設定や TUN の必要性を調べます。TUN を使う場合も、社内 VPN などとの競合を先に確認してください。
日本国内のサイトを直結にしたのに遅いのはなぜですか？
ルールの順序や DNS、IPv6、Wi-Fi の状態、社内ネットワーク側の制約など、原因は複数考えられます。接続ログで対象通信が本当に DIRECT になっているか確認し、Clash 以外の要因も分けて調べてください。ルール変更後に症状が出た場合は、変更前のプロファイルと比較するのが近道です。
安定した在宅勤務のために
すべての通信を一律に転送する VPN 型ツールでは、国内サイトや社内システムまで迂回してしまい、問題の原因を切り分けにくくなることがあります。一方、Clash はルールと接続ログを使って、会議用通信、国内サービス、社内 LAN の経路を個別に確認・調整できます。設定には利用中のプロファイルやサービス要件の確認が必要ですが、変更範囲を小さく保ち、実際の通話で検証できる点は在宅勤務の運用に役立ちます。まずは使っているデスクトップ環境に合うクライアントを確認し、無理のない構成から試してください。