Zoom・Teamsの会議中に音声が途切れる、映像が乱れる、画面共有が止まる場合に、Shadowrocketの設定とネットワークを順に確認するための記事です。自分のサブスクリプションを読み込み済みであることを前提に、UDP通信の扱い、ノードの比較、Global RoutingとConfigの確認、Wi-Fiとモバイル通信での切り分けを説明します。会議サービスの通信要件や利用可能な接続先は環境によって異なるため、特定のノードやルールが常に最適とは限りません。サブスクリプションリンクはご利用のサービス提供元から入手してください。
1. 会議の症状を分けて原因を考える
会議では、音声、映像、画面共有が同時に同じ経路を使うとは限りません。会議へのサインインや参加はできるのに、話し始めると音声が途切れる、映像だけが止まる、共有画面の更新が遅れる、といった症状が起こることがあります。こうした場合、Shadowrocketの接続スイッチがオンであることだけでは、会議のすべての通信が正常に通っているとは判断できません。
まず、問題が始まるタイミングと範囲を記録します。参加直後から失敗するのか、数分後に音声が乱れるのか、特定のWi-Fiだけで起こるのかを分けてください。会議中にGlobal Routingやノードを何度も切り替えると、経路変更そのものが一時的な切断を起こし、原因を判別しにくくなります。会議を終了してから、一度に一つの条件だけを変えて確認しましょう。
音声や映像は、わずかな遅延よりもパケットロスや遅延の揺れに影響されることがあります。一方、Homeで表示される遅延テストの値は、会議中の音声品質や連続した映像転送を直接測定するものではありません。小さい数値が出たノードでも会議が安定するとは限らず、数値が少し大きくても途切れず使える場合があります。
2. UDPとルールの関係を確認する
リアルタイム会議では、音声や映像の通信にUDPが使われる場合があります。ただし、UDPが利用できるか、どの宛先やポートを使うかは会議サービスの仕様、アプリの状態、ネットワーク側の制限によって異なります。UDPの通信が制限された環境では、通信方式が切り替わったり、接続の確立に時間がかかったりする可能性があります。一般的なポート番号だけを見て、Shadowrocket側で任意のポートを開放すれば解決すると考えないでください。
Shadowrocketでは、Home → Global Routingで全体のルーティング状態を確認し、Configを使っている場合はConfig内のルールと選択中の設定ファイルを確認します。ルールは通信の行き先を決めるもので、会議アプリの映像品質そのものを改善する設定ではありません。ドメインに一致するルールを追加しても、サービスが使うすべてのドメインや通信方式を網羅できるとは限らず、認証、会議参加、メディア配信が別の接続先を使う可能性もあります。
会議時の経路を比べる：直接接続とプロキシ接続
DIRECTで確認
- 現在のネットワークから会議サービスへ直接接続する
- プロキシ経由で起こる遅延やUDPの相性を切り分ける
- ネットワーク側の制限や到達性は別途確認する
プロキシ経由で確認
- 選択中のノードを通る経路で会議を試す
- ノードまでの経路と接続先の応答を合わせて見る
- プロキシがUDPを含む会議通信に適合するとは限らない
一方の設定が常に優れているわけではありません。同じ会議、同じネットワーク、同じ時間帯に近い条件で比較し、終了後は普段のGlobal Routingへ戻してください。
会議サービスの公式なネットワーク要件を確認できる場合は、その情報を優先してください。Configのルールを試すときは、サービスが公表する宛先情報と自分の環境を照らし合わせ、対象範囲を限定します。広いDOMAIN-SUFFIXルールを推測で追加したり、FINALの位置を不用意に変えたりすると、会議以外の通信まで影響を受けることがあります。
3. Homeから設定を変えずに会議を比較する
テスト前に、現在のノード、Global Routingのモード、使用ネットワークを記録してください。サブスクリプション管理下の設定を編集する場合、更新によって値が置き換わることもあります。最初は選択中の設定を確認するだけにし、原因が絞れてから必要な変更を一つずつ行います。
-
ネットワークを記録
Wi-Fi名またはモバイル通信の別、発生時刻、会議の症状を記録します。公衆Wi-Fiの場合は、サインインや利用条件への同意を済ませてからテストしてください。
-
ルーティングを確認
Home → Global Routingを開き、Config、Proxy、Directのどれが選ばれているか記録します。Configの場合は、Configで現在使われているファイルも確認し、意図したルールが有効かを調べます。
-
ノードを固定
Homeで現在の接続先を確認し、比較中は同じノードを使います。ノードを変更する場合は一度に一つだけ変更し、会議サービスへの参加、音声、映像、画面共有をそれぞれ確認します。
-
会議を短く試す
会議に参加し、まず音声を数分確認してから、映像と画面共有を個別に試します。問題が出た時刻、途切れた機能、Shadowrocketの接続状態を記録します。遅延テストの数値だけを会議品質の判定に使わないでください。
-
別の回線で再試行
設定とノードを変えずに、Wi-Fiとモバイル通信で同じ確認を行います。Wi-Fiだけで再現するか、両方で起きるかを分けると、ローカルネットワークとプロキシ設定のどちらを先に調べるか判断しやすくなります。
Proxyでの確認は、Config内のルールが原因かどうかを切り分ける一時的な方法になります。テストが終わったら、記録しておいたGlobal Routingの状態に戻してください。Proxyに切り替えて会議が改善しても、それだけで常時Proxyが適切だとは言えません。ルールに問題があったのか、通信経路の差だったのかを個別に確認しましょう。
4. 会議に使うノードは再現性を重視する
候補を比較するときは、ノード名に含まれる地域表示や、1回だけ測った遅延値で決めないでください。Homeで候補を一つずつ選び、同じネットワーク、同じGlobal Routing、同じ会議サービスで確認します。短いConnectivity Testで接続状態を見た後、実際の会議で音声の途切れや映像の停止が起きないか確かめることが重要です。
| 確認結果 | 読み取れること | 次の確認 |
|---|---|---|
| 遅延は小さいが音声が途切れる | 遅延の値だけでは、UDP通信やパケットロスの状態を判断できない | 同じ条件で別の候補を試し、Wi-Fiとモバイル通信の差も確認する |
| 会議には参加できるが映像が止まる | 参加時の接続と、会議中のメディア通信は別に確認する必要がある | 映像をオフにした場合、音声だけの場合と症状が変わるかを確認する |
| Wi-Fiでは失敗し、モバイル通信では安定する | Wi-Fi側の認証、混雑、通信制限などが関係している可能性がある | 同じ設定のままWi-Fiの状態を確認し、ネットワーク管理者の制限も調べる |
| 複数の回線と候補で同じ症状が出る | ノードだけでなく、設定、端末、会議サービス側の状況も確認が必要 | Global Routing、Configの選択状態、サービスの障害情報を順に確認する |
候補ごとに「接続できたか」「音声が継続したか」「映像や共有が止まったか」を分けて記録すると、数字に表れにくい安定性を比べられます。短時間に何度も切り替えると、会議の再接続やサーバー負荷が結果に影響するため、条件をそろえて時間を空けて試してください。特定の地域やプロトコルがどの回線でも有利だと決めつけず、自分の利用環境で繰り返し安定する候補を選びます。
5. うまくいかないときは症状から切り分ける
会議中に問題が起きた場合は、まず音声・映像・共有のどれに影響したかを記録し、接続スイッチの状態だけで原因を決めないようにします。Settings → Connectivity Testは接続確認の補助として利用できますが、会議アプリ内部のメディア品質を測定するものではありません。会議を終了してから、HomeとGlobal Routingの状態を確認し、同じ条件で再現するか試してください。
会議には入れるのに、音声だけ途切れます
会議参加と音声通信を分けて確認します。映像をオフにして音声だけで試し、同じノードのままWi-Fiとモバイル通信を比較してください。Wi-Fiだけで起きるなら、まずWi-Fi側の混雑や制限を確認します。
Proxyにすると直りますが、Configでは不安定です
Home → Global RoutingでConfigを選び、Configで対象ファイルが有効か確認します。続いて会議に関係する通信に適用されたルールを調べます。ルールを変更する場合は対象を限定し、一度に複数のルールを変更しないでください。
遅延テストが成功しても、画面共有が止まります
遅延テストの成功は、画面共有の連続転送が安定していることを示しません。共有を停止して音声と映像を個別に確認し、別の回線でも同じノードを試してください。発生時刻と該当機能を記録すると、ネットワーク側やサービス側の確認に役立ちます。
設定ファイルを変更する前には、元の状態を保存し、問題が悪化した場合に戻せるようにしてください。診断記録やスクリーンショットを共有する際は、サブスクリプションURL、認証情報、個人情報を隠します。サービスの必要な宛先やUDPの扱いが判断できない場合は、利用中のサービス提供元やネットワーク管理者に、記録した症状とネットワーク条件を伝えて確認してください。