この記事で分かること
在宅勤務で Zoom の会議が途切れたり、Slack の通知やファイル送信が遅れたりすると、回線速度だけを疑いがちです。しかし実際には、すべての通信を同じプロキシへ送っていること、会議用ノードの遅延や混雑、国内サービスまで遠回りさせていることが原因になる場合があります。本稿では、Clash Verge Rev や Mihomo 系クライアントを前提に、リモートワークで使いやすい分岐ルールとノード選択の考え方を整理します。
目標は、Zoom の音声・映像、Slack の WebSocket 接続、社内サービス、国内の業務サイトを同じ設定で無理に処理することではありません。用途に応じて DIRECT と PROXY を分け、必要な通信だけ安定したノードへ送ります。さらに、会議前の確認方法、通知が遅いときのログの見方、システムプロキシと TUN の使い分けまで、実際の勤務環境で再利用しやすい手順として説明します。
リモートワークでは通信を三つに分けて考える
最初に、仕事で使う通信を「国内の業務通信」「海外サービス」「リアルタイム通信」の三つに分けます。この分類をせず、プロファイル全体をグローバルな PROXY にすると、社内ポータルや国内の勤怠サイトまで遠い出口を経由し、表示やログインが遅くなることがあります。反対にすべてを DIRECT にすると、特定の SaaS や外部 API だけ接続が不安定になる可能性があります。
- 国内の業務サービス：社内ポータル、勤怠、銀行、宅配、国内 CDN などは、原則として DIRECT にします。
- 海外の業務サービス：Slack、Google Workspace、GitHub、外部のチケット管理などは、実際の接続状況に応じて PROXY を検討します。
- リアルタイム通信：Zoom の会議、画面共有、音声、Slack の常時接続は、一般の Web 閲覧とは別に遅延と安定性を確認します。
ここで注意したいのは、サービス名だけで通信内容を完全に分類できないことです。Zoom や Slack はログイン、API、画像配信、ファイル保存、音声・映像の中継など複数のホストを使います。最初からドメインを大量に登録するより、Clash の接続ログで実際に表示されたホストを確認し、必要なルールを少しずつ追加する方が、誤分岐や過剰な PROXY を防げます。
Zoom を安定させる分岐ルールとノード選択
Zoom は単純な Web ページではありません。サインインや会議情報の取得には HTTPS が使われ、会議中は音声・映像・画面共有のために複数の接続が維持されます。ブラウザだけでテストして「問題ない」と判断しても、会議に入った途端に音声が遅れたり、画面共有だけが止まったりすることがあります。そのため、Zoom の確認は会議への参加、マイク接続、カメラ映像、画面共有、退出までを一つの流れとして行います。
Clash のルール設定では、まず利用地域と勤務先の要件を確認します。会社が指定した VPN やゼロトラスト製品を使っている場合、Zoom の通信を別のプロキシへ重ねると、接続先の地域判定や UDP の扱いが変わることがあります。会社のネットワークポリシーがある場合はそれを優先し、個人の回線で利用する範囲でも、会議中に不要な経路変更をしないようにします。
- 会議前に、現在のノードの遅延だけでなく、数分間の接続安定性を確認する。
- 高負荷なストリーミング用ノードではなく、混雑が少なく応答が安定したノードを選ぶ。
- 音声が途切れる場合は、速度ランキングだけでなく、パケット損失や接続の再試行をログで見る。
- Zoom の会議中にノードを手動変更しない。必要なら会議終了後に別ノードで再テストする。
ノード選択では、最も低い ping のノードが常に最適とは限りません。ping が短くても、会議時間帯に帯域が混雑していると、音声や映像の品質が落ちます。逆に数ミリ秒だけ遅いノードでも、長時間の接続が安定し、上り方向の揺らぎが少なければ実用上は快適です。朝の始業前、昼休み、夕方など時間帯を変えて確認すると、混雑による差を見つけやすくなります。
Slack の通知遅延とファイル転送を切り分ける
Slack でよくある症状は、メッセージ一覧は表示されるのに通知が遅れる、送信済みの表示がすぐ変わらない、ファイルのプレビューだけ開かない、といった部分的な不具合です。これは Slack が一つの接続だけで動いているわけではなく、ワークスペースの API、リアルタイム更新用の接続、画像やファイルを配信する別ホストを使うためです。したがって、Slack のトップページが開くかどうかだけでは十分な確認になりません。
まず Clash のログを開いた状態で Slack を再読み込みし、ログイン、チャンネル表示、メッセージ送信、ファイルのダウンロードを順番に実行します。各操作の直後にどのホストが現れ、どのポリシーへマッチしたかを確認してください。Slack 本体は PROXY なのに、ファイル配信先だけ DIRECT へ落ちている場合や、逆に国内の画像 CDN まで PROXY になっている場合があります。
通知が遅いときは、アプリを何度も再起動する前に、次の点を確認します。
- Clash のルールモードが意図したプロファイルになっているか。
- Slack デスクトップアプリとブラウザが、異なるプロキシ設定を読んでいないか。
- システムプロキシを切り替えた直後に、古い接続が残っていないか。
- スリープ復帰後にネットワークが変わり、Slack の常時接続が再確立されているか。
- ファイルだけ失敗する場合、ファイル配信ホストがログに出ているか。
Slack のような常時接続型サービスでは、ノードを頻繁に自動切り替えする設定が逆効果になることがあります。自動 URL テストで一時的に速いノードへ移っても、既存の接続が切れ、通知の再接続に時間がかかる場合があるためです。勤務中はノードを固定し、休憩時間や業務終了後に速度と安定性を再評価する運用が現実的です。
ルールの順序とシステムプロキシ・TUN の使い分け
Clash のルールは、上から順番に評価されることが基本です。広い条件を先に置くと、後から追加した Zoom や Slack 用の条件に到達しません。たとえば、先頭付近にすべての通信を対象にするルールや、広範囲の地域ルールがある場合、個別のドメインルールが実質的に無効になることがあります。変更後は設定を保存するだけでなく、接続ログで実際のマッチ結果を確認してください。
一般的なデスクトップ作業では、まず ルールモードとシステムプロキシから始めるのが安全です。ブラウザや多くの GUI アプリは OS のプロキシ設定を利用でき、どの通信を送るかを Clash のログで追いやすいからです。国内サービスを DIRECT に残したい場合も、ルールによる分岐を説明しやすくなります。
一方、アプリが OS のプロキシを読まない、Slack の補助プロセスだけ直結する、あるいは特定の業務ツールが環境変数だけを参照するといった場合は、システムプロキシだけでは不十分です。その場合はアプリ側のプロキシ設定を確認し、必要に応じて HTTP_PROXY、HTTPS_PROXY、NO_PROXY などを設定します。社内アドレスや localhost を NO_PROXY に含めないと、社内ツールまで Clash に送られることがあるため、値を漫然とコピーしないでください。
TUN は、アプリがプロキシ設定を無視する場合に有効な選択肢です。プロセス単位の設定に依存せず、より低いレイヤーで通信を取り込める一方、社内 VPN、仮想ネットワーク、セキュリティソフト、IPv6 と競合することがあります。TUN を有効にするなら、最初は短時間の検証に限定し、社内リソース、プリンター、ファイル共有、Zoom の音声を順番に確認します。問題が出たら、すぐに複数の設定を同時変更せず、TUN を戻して原因を一つに絞ります。
会議前の確認手順とトラブルシューティング
勤務開始前に五分程度のチェックを習慣化すると、会議中の設定変更を減らせます。最初に Clash の稼働状態、プロファイル、モード、選択中のノードを確認します。次にブラウザで業務サイトを開き、国内サービスが意図せず遠回りしていないかを見ます。その後 Slack でテストメッセージを送信し、別のチャンネルを開き、必要なら小さなファイルを一つだけ送ります。最後に Zoom のテスト会議でマイク、スピーカー、カメラ、画面共有を確認します。
- 状態確認：Clash が停止していないか、ルールモードが選ばれているか、購読プロファイルが古くないかを確認します。
- 経路確認：業務サイト、Slack、Zoom を個別に操作し、ログのホスト名と策略グループを記録します。
- 品質確認：ノードの遅延だけでなく、接続の切断、再接続、音声の欠落、アップロードの失敗を見ます。
- 再現確認：問題が起きた操作を一つだけ繰り返し、ルール変更前後で結果を比較します。
Zoom の映像が止まる場合は、まず Wi-Fi の電波、他の大容量アップロード、会社 VPN の状態を確認します。Clash のノードを変えて改善したとしても、原因が必ずプロキシとは限りません。Slack の通知だけが遅い場合は、アプリのバックグラウンド制限やスリープ復帰も確認します。ログに接続が出ていないならルール以前にアプリがプロキシを利用していない可能性があり、ログには出ているのに切断されるならノード、TLS、上流回線の品質を調べます。
設定を安定させるため、変更履歴を簡単に残すことも有効です。「ノード変更」「TUN 有効化」「Slack のファイル配信ルール追加」のように変更内容と時刻をメモしておけば、次の障害時に元へ戻す判断が早くなります。仕事用のプロファイルは、実験用のルールと分け、検証が終わっていない自動切り替えや広すぎるルールをそのまま常用しないようにしてください。
長期運用で快適さを保つための設定方針
リモートワーク向けの Clash 設定は、一度作って終わりではありません。Slack や Zoom のアプリ更新、プロバイダ側のノード変更、会社 VPN の更新によって、接続先や挙動が変わることがあります。購読を更新した後は、以前と同じノード名でも実体が変わっている可能性があるため、業務開始前に短い疎通テストを行います。
ルールは「すべてを PROXY」「すべてを DIRECT」の二択にせず、業務上必要な範囲で分けます。国内の社内サービスは DIRECT、特定の外部サービスは安定した PROXY、判断できない通信はログを見てから決めるという順序にすると、トラブルの説明がしやすくなります。ノードの自動選択を使う場合も、会議中に切り替わらないグループを用意し、勤務時間外にテストする方が安全です。
また、会社の規程や利用地域の法律、情報セキュリティ方針を必ず確認してください。業務データを扱う通信では、プロキシの運営者、ログの保存、社内 VPN との併用条件を把握する必要があります。Clash は経路を柔軟に制御できるツールですが、適切なノードを選ぶことや、機密情報を不要な経路へ送らないことまで自動で保証するものではありません。
専用のビデオ会議アプリは設定項目が少ないツールだと全通信を一括処理しがちで、社内サイトまで遠回りしたり、通知と会議で別の問題が起きたときに原因を追いにくいことがあります。Clash なら Zoom・Slack・国内業務サイトをルールとログで分け、ノードを固定して比較し、必要な場合だけ TUN へ段階的に移行できます。複数のクライアントを試しても設定の粒度やログの見やすさに不満があるなら、まず自分の勤務パターンに合わせてこの分岐構成を組める Clash を選ぶと、会議前の確認から障害対応まで一つの流れにまとめやすくなります。