Shadowrocketの通信量の見方｜サーバー別・アプリ別の統計を解説

1. Dataに記録されるのは通信量で、購入した容量ではない

ShadowrocketのDataでは、アプリに記録されたネットワーク通信を確認できます。まずHomeで接続状態を確認し、Dataを開いて統計を見ます。統計に反映されるのは、該当する記録範囲内の通信です。接続を切っている間の通信、トンネルを通らない通信、システムが別の経路で処理した通信が記録されているとは限りません。

アップロードはデバイスから外部へ送信したデータ、ダウンロードはデバイスが受信したデータを示します。Webページの閲覧中にも、リクエストやヘッダー、操作データの送信が発生します。アップロード量が増えていても、ファイルを送信中とは限りません。ダウンロード量が増えていても、ページの内容がすべて表示されたとは限りません。

この流れは確認の順序を理解するためのもので、アプリ内部の処理を示すものではありません。ルールは接続先の経路を決め、統計は接続で送受信されたデータ量を示します。接続に失敗する前に少量のデータがやり取りされることもあるため、数値の増加だけでは通信が成功したとは判断できません。

2. サーバー別とアプリ別の統計：異なる分類を重複して加算しない

サーバー別の表示では、特定のサーバー項目がどれだけ通信を処理したかを確認します。アプリ別の表示では、通信がどの送信元に属するかを確認します。2つの表示は、同じネットワーク通信を異なる切り口で整理したものです。サーバー別の合計とアプリ別の合計を足して、デバイス全体の通信量としてはいけません。

アプリの分類は、現在のData画面で実際に表示されるグループと識別結果を基準にしてください。Appleプラットフォームのネットワークトンネルでは、すべての接続に明確なアプリ名が付くとは限りません。識別できない送信元、システムプロセス、統合された記録を、無理に特定のアプリに割り当てないでください。現在の画面に該当する分類がない場合、ドメイン一覧をアプリ一覧として扱わないようにしましょう。

1つのアプリが、ログイン用API、画像ドメイン、コンテンツ配信ドメインへ同時にリクエストを送ることがあります。接続ごとに異なるルールが適用される可能性もあります。そのため、「このアプリが大量にダウンロードした」ことと「このアプリの通信がすべて特定のサーバーを経由した」ことは同じ意味ではありません。振り分けを確認するには、宛先と実際の出力先をさらに調べる必要があります。

3. ルールの動作を確認する前にGlobal Routingを確認

Home → Global Routingで現在のモードを確認します。Proxy、Direct、Config、Sceneの選択によって、通信のルーティング方法が変わります。設定ファイル内のルールをテストする場合はConfigを選び、Configで現在選択されているファイルも確認してください。ファイルを編集しただけで選択していない場合、その設定内容が統計に自動反映されるわけではありません。

• Proxy：プロキシモードで通信を処理します。この状態でサーバーの通信量が増えても、設定ファイル内の特定の振り分けルールが適用された証拠にはなりません。
• Direct：直接接続モードで通信を処理します。プロキシサーバーの通信量が増えなくても、接続や統計機能の異常とは限りません。
• Config：現在の設定に基づいて通信を振り分けます。出力先を判断するには、ルールの順序、ポリシー名、最終ルールを確認してください。
• Scene：シーン設定に基づいてルーティングします。テスト前に実際に適用されているシーンを確認してください。ホーム画面で選択されているサーバー名だけでは判断できません。

以下の設定例は確認項目を説明するもので、既存の設定を置き換えるためのものではありません。example.comと192.0.2.0/24は構文説明用であり、利用可能なサービスを示すものではありません。PROXYの最終的な出力先は、現在選択されているサーバーまたはポリシーグループも確認してください。

4. 短時間のテストで通信量の増加分を確認

比較するには、同じ統計範囲で確認する必要があります。現在の数値を記録してから単一の操作を行い、最後に差分を計算します。テストのたびに過去の記録を消去する必要はありません。画面にリセット操作がある場合は、必要な数値を先に保存し、リセット時刻も記録してください。サーバーの切り替えや再接続で累計値が必ずリセットされるとは限りません。

1. 基準値を記録：Dataで対象サーバーのアップロード量とダウンロード量、記録時刻を控えます。Homeの接続状態とGlobal Routingも確認します。
2. 影響を減らす：進行中の大容量転送、動画再生、同期タスクを一時停止します。必要なシステム動作はそのままにし、バックグラウンド通信が完全になくなるとは考えないでください。
3. 単一の操作を実行：アクセス権があり、繰り返しテストできるページを1つ開き、読み込みが終わるまで待ちます。実際にアクセスしたドメインと開始・終了時刻を記録します。
4. 差分を確認：Dataに戻り、終了時の数値から基準値を引きます。比較する数値は、同じ項目、同じ方向、同じ単位である必要があります。
5. 記録と照合：確認できる接続詳細やログで該当時間帯を調べ、宛先、ルール、ポリシーを確認します。記録が不十分な場合は、条件を変えずにもう一度テストしてください。

以下は計算方法の例であり、製品で測定した結果ではありません。あるサーバーのダウンロード量が120 MBから126 MBに、アップロード量が8.0 MBから8.2 MBに増えたとします。この場合、表示値の増加分はそれぞれ6 MBと0.2 MBです。これは該当時間帯の統計上の増加分であり、「このWebページの容量がちょうど6 MB」とは言えません。

ダウンロードの増加分 = 126 MB - 120 MB = 6 MB
アップロードの増加分 = 8.2 MB - 8.0 MB = 0.2 MB
比較の条件 = 同じ項目 + 同じ統計範囲 + 同じ単位

表示値が丸められている場合、少量のリクエストでは変化がすぐに見えないことがあります。Webキャッシュによって再転送されるデータ量が減る場合もあります。2回目の読み込みが明らかに速く、通信量の増加がわずかな場合は、まずキャッシュの利用を確認し、すぐにルールが機能していないと判断しないでください。ページ遷移、画像、バックグラウンドリクエストで別のドメインにアクセスすることもあるため、実際の接続を照合する必要があります。

5. 通信量が想定と異なるときは、まず記録範囲を確認

接続スイッチが自動条件の影響を受けているケースもあります。Settings → On Demandを開き、現在の接続条件を確認してください。テスト中にWi-Fiやモバイル通信が切り替わったかも記録します。On Demandは接続を開始する条件を制御するもので、アプリごとに統計ラベルを割り当てる機能ではありません。調査では「トンネルが確立しているか」と「通信がどこに分類されるか」を分けて考えてください。

6. ルールによる振り分けを確認するための最低限の根拠

Dataは「どの項目が増えているか」をすばやく見つけるのに適し、接続記録は「なぜその経路を通ったか」を確認するのに役立ちます。併用する場合は、宛先とルーティング条件を固定してから、実際の出力先を確認してください。統計一覧で特定のサーバーが先頭にあるという理由だけで、すべてのリクエストがそのサーバーを経由したと判断しないでください。

• 宛先が一致：記録するのはページタイトルだけでなく、実際のリクエスト先のドメインまたはIPアドレスです。リダイレクト後のアドレスとリソースのドメインも個別に確認します。
• 条件が一致：テストの間、Home → Global Routing、Configファイル、サーバーまたはポリシーグループの選択を変えないようにします。
• 記録が一致：接続記録のルールとポリシーが想定どおりで、Dataの該当項目の増加分もテスト時刻と対応していることを確認します。
• 結果を再現できる：明らかなバックグラウンド通信とキャッシュの影響を除いたうえで再テストし、同じ出力先になることを確認します。

接続に失敗する原因をさらに調べる場合はトラブルシューティングを、設定ファイルの整理や診断方法についてはトラブルシューティングマニュアルをご覧ください。確認は手元にある設定とサービスをもとに行い、通信量の合計だけで接続状態を判断しないでください。