Shadowrocketの通信量の見方｜Dataでサーバー別・アプリ別の使用量を確認

1. Dataの2つの集計方法を確認する

ShadowrocketのDataでは通信量を確認できます。サーバー別表示では「どのプロキシサーバーを経由したか」、アプリ別表示では「どのアプリの通信として識別されたか」が分かります。同じネットワーク通信を異なる角度から見たものなので、単純に合算すると二重計上になる場合があります。

Dataを開いたら、まずサーバー別・アプリ別のどちらが表示されているか確認し、一覧の累計値を見ます。先頭の項目が現在接続中のサーバーとは限りません。また、アプリが個別に表示されていないからといって、通信していないとは限りません。アプリ別の情報をシステムが提供できるか、通信が現在の集計対象に含まれるかによって表示は変わります。

サーバー別に見る場合、同じアプリが時間帯によって別のサーバーを使うことがあります。アプリ別に見る場合も、1つのアプリが直結とプロキシ接続を同時に行うことがあります。そのため、「アプリの通信量」と「サーバーの通信量」が一対一で一致する必要はありません。比較するときは異なる時刻の累計値ではなく、同じ時間帯にそろえてください。

2. 上り・下り・累計・速度の見方

上りは端末を基準に外部へ送信するデータ、下りは端末が受信するデータです。Webページの閲覧では下りが多くなりがちですが、検索語やリクエストヘッダー、確認応答などの上り通信も発生します。写真のアップロードでは上りが中心になりますが、サーバーからの確認応答やページの返答もあるため、反対方向の通信がゼロになるとは限りません。

ファイルサイズと統計上の増加量が完全には一致しないのは正常です。リクエスト、暗号化のオーバーヘッド、接続確立、再送によってデータ量が増えることがあります。キャッシュ、圧縮、分割リクエストも実際の転送量に影響します。計測位置によって含まれるオーバーヘッドが異なるため、1つの数値からすべての通信が同じ基準で集計されているとは判断できません。

大文字のBと小文字のbを区別してください。Bはバイト、bはビットで、1 B = 8 bです。1 MB/sを回線速度に換算すると約8 Mbpsですが、MBとMiBの単位の違いやプロトコルのオーバーヘッドにも注意が必要です。Dataの累計バイト数は速度測定の結果ではありません。

3. サーバー別の集計で実際の接続先を確認

サーバー別の数値は、「今回のリクエストが想定したサーバーを使ったか」の確認に適しています。Homeでサーバーを選んでも、選択したプロキシが実際に使われるとは限りません。処理先はGlobal Routingとルールによって決まります。Global RoutingがDirectの場合、リクエストは直接接続されるため、サーバーを選択しているだけではプロキシ通信の増加は期待できません。

1. Homeで接続状態、現在のサーバー、Global Routingを確認します。ルール振り分けを確認する場合はConfigモードにし、Configで現在有効な設定ファイルを確かめてください。
2. Dataを開き、対象サーバーの上り・下りの数値と記録時刻を控えます。バックグラウンド通信の影響を減らすため、ほかのダウンロード、クラウド同期、ストリーミング再生は一時停止します。
3. 再現できる操作を1つだけ行います。たとえば、アクセス権のあるWebページからサイズが分かっているファイルをダウンロードします。サーバーの切り替えやルール変更は同時に行わないでください。
4. 操作後にDataへ戻り、数値が更新されるまで待ってから新しい値を記録します。「操作後の値－操作前の値」で増加量を求めます。
5. 次に、該当する接続の宛先、適用ルール、実際の処理方法を確認します。サーバーの増加量は参考情報として使い、個々のリクエストは接続履歴で確認してください。

以下は計算例であり、実測値ではありません。あるサーバーの下りが120 MBから132 MBに、上りが8 MBから8.4 MBに増えた場合、この観測時間帯の増加量はそれぞれ12 MBと0.4 MBです。このサーバーで通信があったことは分かりますが、12 MBすべてが直前に開いたページによるものとは限りません。

4. アプリ別の集計でアプリと接続方法を確認

アプリ別表示は、バックグラウンドのダウンロード、自動再生、同期タスクによる通信を探すときに便利です。対象のアプリを見つけ、同じ時間帯の上り・下りの変化を確認します。アプリに通信量があっても、すべてのリクエストがプロキシを使っているとは限りません。1つのページからメインサイト、画像、動画、解析用の各ドメインへリクエストが送られ、それぞれ異なるルールに振り分けられることがあります。

アプリ名の表示は、システムから提供される情報によって異なります。通信の帰属先を特定できない項目は、その制約を踏まえて扱い、宛先ドメインからアプリ名を推測しないでください。ブラウザーの複数のタブをアプリ全体の通信量だけで区別するのも困難です。特定のページを調べる場合は、テスト時間を短くし、該当する宛先への接続を確認してください。

• アプリを操作していないのに数値が増える：バックグラウンド同期、先読み、自動更新、再生中のメディアを確認します。タスクを一時停止してから、もう一度増加量を記録してください。
• ページを開いても数値がほとんど変わらない：キャッシュから読み込まれたか、通信が現在の集計対象に含まれていない可能性があります。新しいネットワークリクエストが確実に発生する操作で確認してください。
• アプリ別とサーバー別の合計が異なる：まず集計時間をそろえ、直結のリクエスト、別のサーバーを使った通信、アプリに帰属できない通信が含まれていないか確認します。項目ごとの数値を無理に一致させる必要はありません。

端末に想定したアプリ別の項目が表示されなくても、インストール異常とは限りません。まず現在のプラットフォームで利用できる統計項目を確認してください。アプリ別の情報が不足している場合も、サーバーの増加量と接続履歴でルール振り分けを検証できます。

5. DataでConfigのルール振り分けを確認

Dataでは通信量の変化を確認できますが、各ルールが適用された理由までは分かりません。ルールを調べる前に、Home → Global RoutingがConfigになっていることを確認し、Configで現在の設定を確認してください。Proxy、Direct、Sceneはそれぞれ異なるルーティングモードです。別のモードで得た結果を、現在のルールファイルの検証結果として扱わないでください。

ルール行は、ルールの種類、照合する値、ポリシーで構成されます。FINALは最後に適用するポリシーを指定します。以下は構文の例であり、あらゆるネットワーク環境でそのまま使える振り分け設定ではありません。IP-CIDRにはドキュメント用に予約されたアドレス範囲を使用し、実際のサービスを誤って指さないようにしています。

DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,PROXY

ルールは上から順に照合され、一致した時点で処理が決まります。DOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRはアドレス範囲を照合します。IP-CIDRのno-resolveは、このIPルールのためにドメイン解決を開始しないという意味で、アプリ全体のDNSクエリを停止するものではありません。FINALはそれ以前のルールに一致しなかったリクエストに適用されるため、優先して判定するルールより後に配置します。

1. アクセス権のある実際の宛先を使い、先に一致する可能性のある広範なルールより前にドメインルールを配置します。
2. 変更したConfigを保存し、現在その設定が使われていることを確認します。古いページを閉じるか既存の接続を終了してから新しいリクエストを送信し、以前の接続による影響を避けてください。
3. 接続履歴で宛先と適用ポリシーを確認し、Dataのサーバー別増加量と照合します。想定がDIRECTの場合、ページが開けたことだけではプロキシが適用された証拠になりません。
4. テスト後は元の設定に戻します。もともとSceneを使っていた場合は、その選択条件を記録しておき、戻した後のルーティング変更を統計の不具合と取り違えないようにしてください。

6. 通信量の不一致や切断後の増加など、よくある問題

原因を調べる際に、プロトコル、DNS、ルール、サーバーを一度に変更する必要はありません。各テストで変更するのは1項目に絞り、時刻、ネットワークの種類、ルーティングモード、変更前後の数値、接続結果を記録します。「バックグラウンド通信」「ルールの選択」「集計範囲」を切り分けられ、後から同じ条件で再テストしやすくなります。