この記事で分かること
在宅勤務では、Zoom・Google Meet の音声や映像を安定させたい一方で、国内の勤怠システム、社内ポータル、オンラインストレージはできるだけDIRECTで素早く開きたいという要望がよくあります。すべての通信を同じプロキシへ送ると、会議の品質が改善しても国内サービスの表示が遅くなったり、社内ログインで追加認証が発生したりします。
本稿では、Clash Verge Rev などの Clash Verge 系クライアントを前提に、リモートワーク用の分流を組み立てます。Zoom、Google Meet、Slack、Microsoft Teams のような業務アプリをまとめて扱うのではなく、会議、チャット、ファイル同期、国内サービスという用途に分け、プロキシグループ・ルール・システムプロキシ・TUNを順番に見直します。特定のサービスを必ずプロキシへ送るという意味ではなく、利用環境と契約サービスの案内に従い、必要な通信だけを適切な経路へ割り当てる考え方です。
大切なのは、会議中に「何となく遅い」と感じたとき、すぐにノードを交換することではありません。Clash のログで接続先ホスト、マッチしたルール、使用したグループを確認し、DNS、経路、端末側のプロキシ解釈を分けて調べることが、再現性のある改善につながります。
在宅勤務の通信を用途別に分ける考え方
業務アプリは同じ会社のサービスでも、通信の性質が異なります。Zoom の会議は音声と映像のリアルタイム性が重要で、Slack はメッセージだけなら小さな HTTPS 通信が中心ですが、ファイル共有やハドルでは別の接続先が増えます。Google Meet もログイン、会議制御、映像ストリームが完全に同じホストだけで完結するとは限りません。そのため、アプリ名だけを一つのルールに書けば終わるとは考えないほうが安全です。
| 用途 | 基本方針 | 確認したい点 |
|---|---|---|
| Zoom・Google Meet | 必要な接続先を同じ安定グループへ送る | 音声の遅延、映像の停止、会議中の切断 |
| Slack・Teams | チャットと通話・ファイル転送をログで分けて確認する | 通知遅延、画像や添付ファイルの取得、再接続 |
| 勤怠・銀行・行政サービス | 信頼できる国内接続先は原則 DIRECT | ログイン制限、地域判定、社内ポリシー |
| 社内 VPN・社内ドメイン | 会社の指定経路を優先し、勝手に TUN へ流さない | 名前解決、認証、経路の競合 |
たとえば、自宅回線から国内の勤怠サイトへアクセスするだけなら、プロキシを経由させないほうが応答は短くなりやすいです。一方、会議サービスの一部が現在のネットワークから不安定な場合は、会議用に選んだグループへ送ることで改善できる可能性があります。ただし、映像の遅延はプロキシだけでなく Wi-Fi の混雑、上り帯域、CPU 使用率、カメラの解像度にも左右されます。Clash はネットワーク経路を整える道具であり、すべての会議品質を自動的に保証するものではありません。
最初から巨大なルールリストを作ると、どの設定が効果を出したのか分からなくなります。まずは「国内サービス」「会議サービス」「社内ネットワーク」「その他」の四つ程度に分け、ログに現れたホストだけを追加するのが実務的です。サービスの仕様変更で接続先が増えた場合も、通信を一度に全許可するのではなく、アプリの公式情報や管理者の案内と照合してからルールへ反映します。
Clash Verge 系クライアントで行う設定手順
ここからは、Clash Verge Rev や Mihomo コアを利用するクライアントで共通しやすい順序を説明します。画面上の項目名はバージョンによって「Profiles」「Proxies」「Rules」「TUN」など英語表記になっている場合があります。設定を変更する前に、現在のプロファイルを複製するか、購読プロファイルを再取得できる状態にしておくと、失敗したときに戻しやすくなります。
- プロファイルを確認する：購読 URL から読み込んだ YAML が最新か確認します。プロキシグループ名、ルールプロバイダー、DNS 設定が想定どおりかを見て、複数の古いプロファイルを同時に有効にしないようにします。
- 会議用グループを選ぶ：Proxies 画面で、速度だけではなく接続の安定性を見ます。遅延テストの数値が低くても、会議中に切断が多いノードは候補から外します。可能なら同じ地域の候補を二つ以上残し、障害時に手動で切り替えられるようにします。
- ルールモードを確認する：Global ではなく Rule を基本にします。国内サービスを必要以上に遠い経路へ送らず、登録済みの会議関連ルールだけを指定グループへ送るためです。ルールの順序は重要で、広い MATCH や GEOIP の前に、明示的なドメインルールを置きます。
- ログを開いたままテストする：Zoom や Meet を完全終了してから再起動し、ログに表示される接続先とポリシー名を確認します。会議へ参加する前のログイン、参加後の音声接続、カメラ開始、画面共有の各場面で接続先が変わることがあります。
- システムプロキシを段階的に有効化する：ブラウザや OS の HTTP 通信を Rule に乗せたい場合だけ有効にします。会社の VPN クライアントやセキュリティソフトが別のプロキシを設定している場合は、先に管理者の指示を確認してください。
- 必要な場合だけ TUN を試す：アプリがシステムプロキシを無視する、または独自の通信方式で接続する場合に限り TUN を検討します。管理者権限、仮想ネットワークアダプター、DNS、IPv6、社内 VPN との競合を確認し、変更後は一つずつ動作テストを行います。
ルールを記述する場合は、プロファイルの形式に合わせてください。Mihomo の設定で一般的な考え方は、会議サービスのドメインを専用グループへ送り、社内ドメインや国内サービスを DIRECT にし、最後に残りの通信を既定グループへ送る構成です。実際のドメイン名やグループ名はプロバイダーのプロファイルに依存するため、存在しないポリシー名を手入力しないことが重要です。設定ファイルを直接編集した場合は、インデント、引用符、グループ名のスペルを確認してから再読み込みします。
会議アプリを再起動せずにルールだけ変更すると、既存の Keep-Alive 接続が古い経路に残ることがあります。切り替え後に改善が見えないときは、アプリを終了し、必要なら Clash の接続一覧から該当セッションを閉じてから再接続してください。ブラウザ版の Meet では、タブを閉じるだけでなくブラウザのサイト接続を再作成する必要がある場合もあります。
TUN、DNS、ノードを切り分ける方法
TUN は、アプリ側がプロキシ設定を読まなくても OS の通信を仮想インターフェースへ取り込める点が強みです。しかし、強力であるほど影響範囲も広くなります。社内 VPN が作る仮想アダプター、エンドポイント保護ソフト、Docker や WSL のネットワークと同時に使うと、経路の優先順位が不明確になり、社内システムだけ開けない、DNS は引けるのに HTTPS が失敗する、といった症状が出ることがあります。
まずシステムプロキシだけでブラウザ版の会議を確認し、次にデスクトップアプリや画面共有を試します。ここでブラウザは動くのにアプリだけ接続できない場合、アプリが独自のプロキシ実装を使っている可能性があります。TUN を有効にする前に、アプリ内にプロキシ設定があるか、会社の端末管理ポリシーで VPN やネットワーク拡張が制限されていないかを確認します。
DNS の問題も見落としやすいポイントです。名前解決が DIRECT、HTTPS 接続が PROXY のように異なる経路へ分かれると、地域判定や CDN の選択が不安定になることがあります。反対に、社内ドメインまで外部 DNS へ送ると、内部アドレスを解決できなくなる場合があります。Clash の DNS モードを変更するときは、国内サイト、社内サイト、会議サービスの三種類をそれぞれ確認し、変更前後の結果を記録してください。
症状と確認箇所を表にすると、切り分けの優先順位を決めやすくなります。
| 症状 | 先に見る場所 | 次の対応 |
|---|---|---|
| 会議参加後に音声だけ途切れる | Wi-Fi の上り、ノードの安定性、UDP の扱い | 別ノードと有線接続で比較する |
| ブラウザ版は動くがアプリ版が失敗する | アプリ内プロキシ、システムプロキシ、TUN | アプリ再起動後にログを比較する |
| Slack の通知だけ遅れる | 長時間接続、スリープ、省電力設定 | 再接続時刻と Clash の接続ログを確認する |
| 国内サイトのログインが繰り返される | DIRECT ルール、DNS、Cookie、VPN 競合 | 対象ドメインを明示して経路を固定する |
ノードの遅延テストは参考値に過ぎません。短い HTTP リクエストが速くても、長時間の音声・映像セッションで安定するとは限らないため、実際の会議で 15 分程度のテストを行うほうが有効です。時間帯、Wi-Fi の周波数帯、同居人の通信、会社 VPN の有無も記録しておくと、Clash の設定だけに原因を求めずに済みます。
また、社用端末ではログに機密性のあるホスト名や社内サービス名が表示されることがあります。ログを外部へ貼り付ける場合は、ユーザー名、会議 ID、社内ドメイン、認証情報を必ず伏せてください。プロキシ設定を変更しても、会社の利用規程や情報セキュリティ部門の指示が優先されます。特に TUN で社内通信を意図せず外部経路へ送る構成は避けるべきです。
会議品質を維持する日常運用
毎回設定を細かく触るより、会議前に確認する項目を固定したほうが安定します。Clash Verge を起動したら、プロファイルの有効期限、現在のプロキシグループ、Rule モードの状態を確認します。次に、ブラウザで国内の業務サイトを開き、DIRECT で正常に表示されるかを見ます。その後、短いテスト通話でマイク、スピーカー、カメラ、画面共有を確認します。
在宅勤務では、家族の動画視聴や OS のアップデートが会議と同じ Wi-Fi を使うことがあります。会議品質が突然落ちた場合は、Clash のノードだけでなく、ルーターの混雑、2.4 GHz と 5 GHz の接続先、バックグラウンド同期も確認してください。Slack や OneDrive などのファイル同期を会議中だけ一時停止すると改善するケースもありますが、社内ルールに反しない範囲で行います。
運用を安定させるには、設定を「会議用」「通常業務用」の二つに増やし過ぎないことも大切です。プロファイルを複数作ると、別のルールや DNS が読み込まれていることに気づきにくくなります。基本は一つの管理しやすいプロファイルにまとめ、プロキシグループの選択だけを切り替えるほうが、トラブル時の説明も簡単です。変更した日時、変更内容、会議での結果を簡単にメモしておけば、同じ症状が出たときに以前の状態へ戻せます。
一般的な VPN アプリだけで業務アプリをまとめて保護しようとすると、国内サービスまで同じ出口へ送られたり、アプリごとの例外設定が増えて管理しにくくなったりします。逆に単純なシステムプロキシ設定だけでは、プロキシを無視するアプリや TUN が必要な通信を扱いにくいことがあります。その点、Clash Verge 系クライアントは、会議サービスをプロキシグループへ送り、勤怠や社内の許可された接続を DIRECT に残し、必要なときだけ TUN へ広げるという段階的な設計を一つの画面で確認できます。設定の影響範囲をログで追いながら在宅勤務の経路を整えたいなら、まず利用環境に合う Clash クライアントを入手して試すのが自然な選択です。