ShadowrocketのData画面で通信量を確認する方法｜サーバー別・アプリ別の見方

Dataの集計範囲：通信量の振り分け先とルールの証拠を区別する

ShadowrocketのData画面では、クライアントが記録した通信量を確認できます。端末上のすべてのネットワーク通信を記録するものではありません。クライアントの処理経路を通らない接続の使用量はここから判断できず、アプリ名の識別や表示粒度もプラットフォームや現在の実装に左右されます。アプリ名が表示されないからといって、そのアプリが通信していないとは限りません。

サーバー別表示では主に「どのサーバーを経由した通信か」を、アプリ別表示では主に「どの識別可能なアプリに属する通信か」を確認できます。同じネットワーク通信を別の切り口で分類したもので、両方の数値を合算するものではありません。また、アプリ一覧の各行がすべてプロキシ経由とは限りません。実際のルーティングと接続記録を確認してください。

この流れは確認手順を理解するためのもので、画面上のすべてのカウンターが同じ段階で計測されることを示すものではありません。統計から「テスト中に特定のサーバーの通信量が増えた」と分かる場合はありますが、「直前にアクセスしたドメインが指定ルールに一致した」とまでは証明できません。後者を確認するには、同じ時間帯のリクエストまたは接続記録で、接続先、適用されたポリシー、実際のアウトバウンド先を照合します。

アップロード・ダウンロード・累計量：単位を確認してから増分を比較

アップロードは端末から送信するデータ、ダウンロードは端末が受信するデータです。Webページを開くとリクエストの送信とレスポンスの受信が通常は同時に発生します。コンテンツ再生中にも、確認パケットや再生位置の報告などのアップロード通信が発生することがあります。そのため、コンテンツを見ているだけなのにアップロードがゼロでないことだけでは、障害とは判断できません。速度は計測時点付近の通信の速さ、累計量は集計期間中に転送されたデータ量を示します。

たとえば、同じ統計項目のダウンロード量がテスト前に120 MB、テスト後に138 MBと表示された場合、この時間帯の表示上の増分は18 MBです。これは計算例であり、実測値やWebページのファイルサイズを保証するものではありません。画面の数値が丸められている場合、短時間の少量通信はすぐに反映されないことがあります。接続がこの経路を通っていないと決めつけず、表示の更新を待つか、観察時間を延ばしてください。

サーバー別・アプリ別の確認：対象を固定して数値を比較

サーバー別に調べる場合は、まずHomeで現在選択されているサーバーを記録し、Configで使用中の設定やポリシーが別のサーバーを選ぶ可能性も確認します。Homeで選択を切り替えても、既存の接続がすべてすぐに移行するとは限りません。ポリシーの選択や接続の再利用が実際のアウトバウンド先に影響することがあります。サーバー名の変更、サブスクリプションの更新、項目の差し替えがあった場合は、名前が似ているという理由だけで新旧の累計値を連続した記録として扱わないでください。

アプリ別に調べる場合は、できるだけ対象アプリだけで新しいネットワークリクエストを1回発生させます。ブラウザーの複数タブ、バックグラウンド同期、アプリ内の先読みは結果に影響します。現在のプラットフォームのData画面で必要なアプリ別情報を確認できない場合は、時間帯と対象ドメインの接続記録を照合してください。識別できない項目を無理に特定のアプリへ割り当てないようにします。

統計をリセットするタイミング：明示的なリセットか基準値の記録を区切りにする

Dataの数値が毎日0時、再接続時、アプリの再起動時に自動でリセットされると決めつけないでください。プロバイダーの課金期間と一致するとも限りません。統計項目によって保持される範囲が異なる場合があります。画面に明記されていない場合は、最後にリセットされた時期を不明として扱い、現在の累計量を「今日の使用量」と呼ばないようにします。

1. まず基準値を記録します。時刻、プラットフォーム、現在の設定、サーバー名、観察する累計値を記録してください。履歴を残す必要がある場合はテキストで記録すれば十分です。テストのために履歴を削除する必要はありません。
2. リセットの対象範囲を確認します。現在のData画面にクリアまたはリセットの操作がある場合は、説明や確認メッセージを読み、現在の項目だけに適用されるのか、すべての統計に適用されるのかを確認してください。ボタン名は現在の画面表示に従います。
3. 必要な場合にのみリセットします。管理されたテストを始める前に操作し、画面が更新されて対象の数値が実際に変化したことを確認してください。テストの途中でリセットすると、前後の差分を同じ基準で比較できなくなります。
4. 明確なリセット操作がない場合は差分を使います。ゼロから始めるためにサーバーや設定を削除したり、再インストールしたりする必要はありません。終了時の値から開始時の値を引く方法が、トラブルの切り分けには適しています。

ルール設定の確認：Configと接続記録でアクセスを検証

ルールを確認するには、まずHome → Global RoutingがConfigになっていることを確認します。Proxy、Direct、Configではルーティングの意図が異なるため、前の2つの設定で行ったテストをカスタムルールの動作確認には使えません。Sceneを使う場合は、現在のシーンで実際に適用されている設定とポリシーも確認します。次にConfigで、ファイルがインポートされているだけでなく、その設定が現在使用中であることを確かめてください。

DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

以下は処理順を説明する例です。ルールは上から順に照合され、一致するとポリシーが適用され、FINALが最後のフォールバックになります。PROXYは設定内で有効なプロキシポリシーを指す必要があります。example.comは例示用のドメインであり、テスト用の接続先ではありません。IP-CIDRとGEOIPはIPアドレスの条件で照合されるため、ドメインの分類と同じものとして扱えません。実際の結果は、接続先の名前解決と接続記録も確認してください。

1. 大容量ファイルの転送やメディア再生を止め、Data画面で関連する統計項目の開始値を記録します。ほかの操作を一時停止するだけでかまいません。バックグラウンド通信が完全になくなったとは考えないでください。
2. 対象アプリで新しいリクエストを1回実行し、アクセス時刻と完全な接続先ドメインを記録します。実際に通信が発生すると確認できる操作を選び、キャッシュ済みのページを開くだけの操作は避けてください。
3. リクエストが終了したらData画面に戻り、同じ統計項目の終了値を記録します。一定時間で比較する場合は60秒などに統一し、一方は数秒、もう一方は数分という差が出ないようにします。
4. 同じ時間帯のリクエストまたは接続記録を確認し、接続先ドメイン、適用されたポリシー、実際のアウトバウンド先を照合します。ルールがDIRECTに一致する場合、そのリクエストによってプロキシサーバーの累計量が増えるとは限りません。
5. 比較テストでは設定を一度に1項目だけ変更し、接続を新たに開始してください。必要に応じて古い接続を終了し、接続の再利用が判断に影響しないようにします。

よくある数値の疑問：請求額との違い、増分ゼロ、切断後の変化

Data画面から分かるのは記録された通信状況であり、Webページの表示が遅い理由を単独で特定することはできません。サーバーへの接続性、DNS、接続先の応答時間、ネットワーク品質はそれぞれ確認してください。接続に問題がある場合はトラブル対処も参照してください。設定は一度に1つだけ変更し、同じ時間枠で再テストすると、変更前後の数値を比較しやすくなります。