在宅勤務で Zoom と Slack だけ不安定になる理由

在宅勤務のネットワークでは、一般的な Web サイトは問題なく開けるのに、Zoom 会議の音声が途切れる、Slack の通知が数分遅れて届く、ファイルのアップロードだけ失敗する、といった現象が起こります。これは単純に回線速度が不足しているとは限りません。Zoom は会議の開始時に HTTPS で認証や設定を取得し、その後は UDP を優先したリアルタイム通信を利用します。一方、Slack は WebSocket による常時接続、ワークスペースの API、画像やファイルを配信する CDN など、複数の接続先を組み合わせています。

そのため、ブラウザだけにシステムプロキシを設定しても、Zoom のデスクトップアプリや Slack の Electron アプリが同じ経路を使うとは限りません。逆に、すべての通信を常時プロキシへ送ると、国内の銀行サイト、プリンター、NAS、社内 VPN、近隣の動画 CDN まで遠回りになり、普段の作業速度やプライバシーに悪影響が出ることがあります。そこで有効なのが、仕事で必要な海外サービスだけを Clash 経由にし、国内通信とローカル通信は DIRECT にする分割ルーティングです。

本稿では、Clash Verge Rev や Mihomo 系クライアントを想定し、Zoom と Slack の接続を安定させる考え方を整理します。特定のホスト名を無制限に追加するのではなく、Clash の接続ログで実際に使われたドメインを確認しながら、サービスごとのルールを小さく保つことが重要です。勤務先の VPN、会社支給端末のセキュリティソフト、通信ログの保存方針がある場合は、個人のプロキシ設定よりも組織の規定を優先してください。

Zoom・Slack向け分割ルーティングの設計

最初に決めるのは、どの通信をプロキシへ送り、どの通信を直接接続するかです。Zoom の会議映像や Slack のワークスペース接続は、利用環境によって海外経路が必要になることがあります。しかし、DNS、ローカルネットワーク、会社の認証基盤まで一括して同じプロキシへ送ると、別の問題を招きます。一般的には、仕事用のプロキシグループを一つ用意し、サービス固有のドメインルールをそのグループへ向けます。

ルールの順序も重要です。Clash は上から順に条件を評価するため、先に広い GEOIP や MATCH を置くと、後から追加した Zoom や Slack のルールへ到達しません。ローカルネットワーク、会社内で直接接続すべき宛先、サービス固有のドメイン、地域ルール、最後の MATCH という順番を基本にします。

rules:
  - DOMAIN-SUFFIX,zoom.us,WORK_PROXY
  - DOMAIN-SUFFIX,zoom.com,WORK_PROXY
  - DOMAIN-SUFFIX,slack.com,WORK_PROXY
  - DOMAIN-SUFFIX,slack-edge.com,WORK_PROXY
  - DOMAIN-SUFFIX,slack-msgs.com,WORK_PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,JP,DIRECT
  - MATCH,PROXY

上の例をそのまま永久に固定するのではなく、実際の接続一覧で不足分を確認してください。Slack のファイル配信や画像表示で別 CDN が使われることもあり、Zoom では会議地域やデータセンターによって接続先が変わります。ログに現れたホストがサービスに関係するものかを確認し、必要な場合だけ DOMAIN-SUFFIX や DOMAIN を追加します。広すぎるドメインをプロキシに送ると、業務と無関係な通信まで巻き込むため注意が必要です。

Clashで仕事用ルールを追加する手順

ここでは Clash Verge Rev、Mihomo Party など、YAML プロファイルを編集できるクライアントを想定します。画面上の名称はバージョンによって「Profiles」「設定」「YAML 編集」など少し異なりますが、作業の順番はほぼ共通です。既存の購読プロファイルを直接書き換えると、次回更新時に内容が消えることがあるため、可能ならローカルのオーバーライド機能やルールプロバイダーを利用してください。

1. 現在のプロファイルをバックアップする：編集前に YAML を保存し、現在選択しているプロキシグループ名と DNS モードをメモします。設定を壊した場合に、バックアップへ戻せる状態を作っておきます。
2. 仕事用プロキシグループを確認する：会議中に安定するノードを一つ選び、必要なら WORK_PROXY のようなグループを作ります。url-test の自動切り替えは便利ですが、長時間の Zoom 会議中に出口が変わると接続が切れる場合があるため、会議用には固定選択を試します。
3. 先に LAN と会社内通信を DIRECT にする：家庭内の 192.168.0.0/16、172.16.0.0/12、10.0.0.0/8 などを直接接続にします。社内 VPN のアドレス帯が別に指定されている場合は、勤務先の資料を確認して追加します。
4. Zoom と Slack のルールを追加する：接続ログで確認したドメインを、広い地域ルールより上に置きます。まずは zoom.us、zoom.com、slack.com など最小限の範囲から始め、必要な CDN だけを後から足します。
5. DNS とモードをそろえる：通常のシステムプロキシでアプリが通信を拾えない場合は TUN モードを検討します。TUN を使うと UDP やプロキシ設定を無視するアプリも対象にできますが、DNS とルート設定の影響が大きくなるため、最初から無条件で有効にしないでください。
6. テスト会議とテストメッセージを行う：Zoom のテストミーティングで音声、映像、画面共有を順番に確認し、Slack では通知、メッセージ送信、ファイル表示を試します。Clash の接続画面で、対象通信が期待したグループを通っているか同時に確認します。

システムプロキシだけで確認する場合は、まず Clash の混合ポートを有効にし、クライアントの「システムプロキシ」をオンにします。Zoom や Slack が接続一覧に現れない場合、アプリが独自のネットワーク処理を使っている可能性があります。そのときはアプリを完全終了してから再起動し、それでも変わらなければ TUN の導入を検討します。TUN を有効にする際は、仮想インターフェースの権限、DNS の hijack、auto-route、既存 VPN との競合を一つずつ確認してください。

Zoom の音声や画面共有では UDP が使われることがあります。TCP のページ読み込みだけ成功しても、UDP が遮断されたノードでは会議品質が下がる場合があります。クライアントの接続ログに UDP の失敗が表示されるなら、別のノードや転送方式を試し、無理にルールを増やす前にノード側の対応状況を確認します。仕事用プロキシを選ぶときは、ダウンロード速度の数値だけでなく、会議時間帯の遅延、パケットロス、接続の継続性を重視してください。

安定性を確認するチェック方法とトラブル対策

設定後は「アプリが開いた」だけで成功と判断せず、利用する機能を分けて確認します。Zoom はログイン、会議参加、音声、カメラ、画面共有の順に試すと、どの段階で失敗しているか分かりやすくなります。Slack はワークスペースの初回読み込み、リアルタイム通知、スレッド表示、ファイルのプレビューを個別に確認します。ブラウザ版だけ動いてデスクトップ版が動かない場合は、アプリのプロキシ継承や TUN の捕捉範囲を疑います。

• Slack が「接続中」のままになる：Slack の WebSocket 接続先が DIRECT に落ちていないか確認します。接続一覧で再接続が繰り返される場合は、ルールの対象ホスト、DNS 解決結果、選択中ノードを順番に見直します。
• Zoom は参加できるが音声だけ途切れる：UDP の利用可否、ノードのパケットロス、家庭内 Wi-Fi の混雑を確認します。Wi-Fi の 2.4GHz 帯が混雑している場合は、5GHz や有線接続に変えるだけで改善することもあります。
• 国内サイトまで遅くなった：広い DOMAIN-SUFFIX、誤った GEOIP ルール、またはグローバルモードを確認します。国内サイトと LAN を DIRECT に戻し、MATCH の動作を最後に確認してください。
• 社内 VPN と同時に使えない：VPN が先にルートを占有している、または TUN が別の仮想インターフェースを優先している可能性があります。勤務先の VPN 仕様を確認し、二重トンネルを避ける構成を担当部署へ相談します。
• 設定更新後にルールが消えた：購読更新で元の YAML が再生成された可能性があります。手動編集ではなくオーバーライド、外部ルール、または管理対象の設定機能へ移行すると再発を抑えられます。

DNS 周りでは、ブラウザがキャッシュした名前解決結果と Clash の記録が一致しないことがあります。設定を変更した後は Zoom と Slack を完全終了し、必要に応じて OS の DNS キャッシュを更新してから再起動してください。Fake-IP を使う場合は、社内ドメイン、プリンター名、家庭内ホスト名を fake-ip-filter に入れないと、ローカル機器が見えなくなることがあります。逆に DNS を OS 側へ逃がしたまま TUN だけ有効にすると、地域判定とルール適用が不安定になることもあるため、DNS の経路は一貫させるのが安全です。

仕事中の切断を減らすには、会議直前に設定を大きく変更しないことも大切です。前日に短いテスト通話を行い、同じ Wi-Fi、同じノード、同じクライアントで十数分の音声と画面共有を確認します。Clash のログには、対象ホスト、使用ルール、プロキシグループ、接続開始と終了の時刻を残します。問題を問い合わせるときは、購読 URL や認証情報を含めず、これらの一般化した情報だけを共有してください。

なお、Zoom や Slack の通信をプロキシへ送ることが、必ずしも会議品質を向上させるとは限りません。国内から公式サーバーへ直接到達できる環境では DIRECT の方が低遅延になる場合もあります。目的は「すべてをプロキシにすること」ではなく、失敗している接続だけを安定した経路へ移し、正常な通信は余計な中継を避けることです。設定前後で遅延、再接続回数、音声の途切れを比較し、改善しないルールは削除するという姿勢が、長期運用では最も扱いやすくなります。

専用の業務ネットワーク機能をうたう一部の VPN ツールは、アプリ単位の分割が簡単な反面、細かなドメイン確認や DNS の挙動を利用者が把握しにくく、企業向け製品は管理ポリシーや料金、環境依存の制約が増えがちです。Clash 公式サイト なら、Zoom・Slack・国内通信・LAN をルール単位で分け、接続ログを見ながら設定を調整できます。クライアントの選択肢と設定例を確認しながら在宅勤務の通信を整えたい方は、まずダウンロードページへ進み、自分の OS に合う環境から無理なく試してみてください。