v2rayNでテレワークを快適にするZoom・Slack振り分け設定

テレワークの通信を用途別に分ける

v2rayNはノードやサブスクリプションを管理し、実際に接続処理とルーティングを行うのはXrayなどのプロキシコアです。Windowsのシステムプロキシは、対応するアプリへローカルプロキシの入口を知らせる設定にすぎません。ZoomやSlackがその設定を読み取るか、独自の接続方式を使うかによって、同じWindows上でも通信の経路は変わります。

テレワークでは、単に「すべてプロキシ」へ設定するより、通信の性質を分けた方が確認しやすくなります。会議アプリは音声と映像を継続的に送受信するため、経路の遅延やパケット損失の影響を受けやすい通信です。Slackはメッセージ、ファイル、通知、音声・ビデオ機能で接続先が異なる場合があります。Google Meetもブラウザー、会議メディア、ログイン関連の通信が完全に同じドメインだけで完結するとは限りません。

10808や10809はv2rayNで使われることがある例示値であり、現在の設定を保証するものではありません。「設定」→「パラメーター設定」などの画面で、HTTP、SOCKS、混合リスニングの実際のポートを確認してください。アプリが直接ローカルポートを指定している場合、システムプロキシを切り替えても、そのアプリの設定は自動更新されません。

Zoom・Slack・Google Meetの規則を設計する

ルールを作る前に、「アプリ名」と「通信先ドメイン」を混同しないことが重要です。ドメイン規則は、コアに入った接続の宛先名やIP情報を基準に経路を選びます。一方、アプリ別プロキシはWindows上の実行ファイルやアプリ単位で通信を選ぶ機能です。v2rayNや使用中のコアがアプリ別ルールに対応しているかを確認し、対応していない場合はドメイン、IP、ポートを中心に設計します。

Zoomでは、ログイン画面だけ開いても会議の音声・映像が正常とは限りません。Zoomの公式ドメインとして利用環境に現れる zoom.us や zoom.com などを候補にし、実際のコアログとWindowsの名前解決結果を照合します。Google Meetでは meet.google.com を入口として確認できますが、認証や関連サービスの通信まで一つの規則で網羅できるとは限りません。Slackも slack.com、app.slack.com、ワークスペースやファイル配信に関係するホスト名を環境ごとに確認してください。

v2rayNでルーティングを設定する手順

画面名はv2rayNの版や選択しているコアによって異なることがあります。以下では、現在使用している設定をバックアップし、変更を一度に増やさない進め方を示します。最初から複数のルール、DNS、TUNを同時に変更すると、会議が失敗した理由を特定しにくくなります。

1. 現在値を確認

   v2rayNで動作確認済みのノードを選択し、コアを起動します。「設定」→「パラメーター設定」でHTTP、SOCKS、混合ポートを記録し、システムプロキシが実際のポートを指していることを確認します。

2. ルーティングを開く

   「設定」→「ルーティング設定」または同等のルーティング管理画面を開きます。既存のルールを上書きせず、現在の設定をエクスポートまたは複製してテスト用の構成を作ります。

3. 業務ドメインを追加

   Zoom、Google Meet、Slackで実際に表示されたホスト名をドメイン規則へ追加します。まず zoom.us、zoom.com、meet.google.com、slack.com などを候補にし、未確認のワイルドカードを大量に登録しないでください。

4. 出站を選択

   追加した規則の出站をプロキシまたは直接接続に設定します。国内サービス用の規則は業務要件を確認したうえで直接接続にし、ルールの上から下へ評価される構成では、より具体的な規則を一般規則より前に置きます。

5. コアを再起動

   設定を保存してコアを再起動します。v2rayNの画面が起動済みでも、変更したルーティングが実行中のコアへ反映されているとは限らないため、ログに設定解析エラーがないことを確認します。

6. アプリ別にテスト

   Zoom、Google Meet、Slackを一度に起動せず、1つずつ接続します。会議では音声、映像、画面共有を個別に確認し、Slackでは通知、投稿、ファイル取得を分けて確認します。

Windows の確認例
設定 → ネットワークとインターネット → プロキシ
v2rayN → 設定 → パラメーター設定
v2rayN → 設定 → ルーティング設定

ルーティングが期待どおりに動かない場合は、まず規則の順序、ドメインの記述形式、DNSの解決場所、出站名を確認します。ドメイン規則を追加したのに通信が直接接続される場合、アプリがシステムプロキシを使っていない、対象ホスト名が別にある、またはDNS情報だけでは規則に一致していない可能性があります。TUNを使う場合は、アプリの通信を仮想インターフェースへ取り込むため、システムプロキシだけでは対象外だった通信もコアへ入るようになります。ただし、TUNの導入は影響範囲が大きいため、まず現在のプロキシ方式で不足しているアプリを特定してください。

会議中の状態を確認して調整する

設定後の確認は、ブラウザーでログインページが表示されるかだけでは不十分です。ZoomまたはGoogle Meetで短いテスト会議を開き、参加直後、マイク送信、カメラ送信、画面共有の順に確認します。Slackは新しいメッセージの受信、投稿、ファイルのアップロードとダウンロードを分けて試します。各テストの前にコアログを消去または区切りを付けると、どの通信がどの規則へ入ったかを追いやすくなります。

音声が途切れる場合は、すぐにノードやプロトコルを変更せず、まず同じ会議を直接接続とプロキシ接続で比較します。直接接続だけが安定するなら、その会議通信を直接にする設計が適切な環境かもしれません。逆に、プロキシ接続だけが安定するなら、会議関連のドメインやUDPを含む通信が同じ経路へ入っているかを確認します。TCPだけを確認してUDPの扱いを見落とすと、ログインは成功しても音声や映像だけが不安定になることがあります。

• Zoomだけ失敗：実際の会議ホスト名、音声・映像の経路、UDPを含む設定を確認します。
• Slackの投稿だけ失敗：ワークスペース固有の接続先、ブラウザー版とデスクトップ版の差、ファイル配信先を確認します。
• Google Meetに参加できるが映像が不安定：会議メディアの経路と、ブラウザーが想定したローカルプロキシを使っているかを確認します。
• 国内サイトまで遅くなった：一般的なプロキシ規則が国内ドメインより先に評価されていないか、直接接続の例外が正しい位置にあるかを確認します。