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

方向・速度・累計通信量を区別する

アップロードとダウンロードは、現在のデバイスを基準に考えます。デバイスから外部へ送信するデータがアップロード、外部から受信するデータがダウンロードです。Webページを開くとリクエストの送信とコンテンツの受信が発生します。動画の再生ではダウンロードが中心ですが、リクエストや確認応答、状態報告などのアップロードもあります。そのため、両方の数値が増えても、異常な接続が発生しているとは限りません。

/sが付く数値は速度、時間あたりの単位が付かないバイト数はデータ量を表します。Homeの接続状態の横に表示される瞬間的な数値と、Dataの累計値はそのまま比較できません。累計値は、ページに表示された集計範囲も踏まえて確認してください。現在の接続、個別の項目、保存された履歴では、集計開始時刻が異なる場合があります。

大文字のBと小文字のbの違いに注意してください。1 Byteは8 bitです。回線速度にはMbps、アプリの転送速度にはMB/sがよく使われ、同じ数値として比較できません。カウンターの単位換算や表示精度も異なる場合があります。比較するときは画面に表示された単位のまま記録し、丸めてから差を計算しないようにしましょう。

サーバー別とアプリ別：異なる集計軸

サーバー別表示では、どのサーバー項目に通信量が計上されたかを確認します。リクエストを送信したアプリを示すものではありません。複数のアプリが同じプロキシの出力先を使う場合、そのサーバーのカウンターはそれらの通信に応じて増加します。Homeで選択中のサーバーが、すべてのリクエストの経由先とは限りません。実際の経路はGlobal Routing、現在のConfig、ルールで指定されたポリシーによっても変わります。

アプリ別表示では、リクエストの送信元がどのアプリに分類されたかを確認します。アプリの接続が異なるポリシーで処理されることがあるため、特定のアプリの通信量を特定のサーバーの通信量と同一視することはできません。送信元を識別できるかどうかは、システムから提供される情報や接続の種類にも左右されます。アプリ名が個別に表示されなくても、そのアプリの通信がなかったとは限りません。現在のData画面にアプリ別表示がない場合は、利用できるサーバー別統計と接続記録を確認してください。ドメイン名をアプリ名として扱わないようにしましょう。

ルーティングを確認してから、増えている項目を判断する

Dataは通信結果を示す数値であり、ルールに一致したことの証明ではありません。Global RoutingがProxyの場合、通常のリクエストはプロキシモードで処理されます。Directの場合は直接接続、Configの場合は現在の設定に基づいて処理されます。Sceneにはシーン設定が関係するため、モード名だけから最終的なポリシーを推測せず、そのシーンで実際に使われている設定を確認してください。

Configモードでは、通常、ルールは上から順に照合されます。DOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRはIPアドレスの範囲、GEOIPはIP位置情報データベースに基づいて判定します。FINALは、それまでのルールに一致しなかったリクエストを処理します。あるリクエストがDIRECTに一致した場合、想定したプロキシサーバーのカウンターが増えなくても、それだけで接続失敗とは判断できません。

1. Homeで現在のGlobal Routingを記録し、現在のサーバー項目を確認します。
2. Configを使っている場合は、名前が似たファイルを開くだけでなく、実際に使用中の設定をConfigで確認します。
3. 対象ドメインに適用されるルール、その前に評価されるルール、FINALを確認します。カウンターを増やすために、すべてのルールを直接書き換えないでください。
4. 接続記録の宛先と実際に適用されたポリシーから通信経路を判断し、Dataに戻って該当項目の変化を確認します。

累計値がリセットされるタイミング：カウンターの範囲を確認する

「接続を終了する」ことを「Dataの記録がすべて消える」ことと混同しないでください。接続を終了すると、そのセッションは終わりますが、過去の累計値が保持されるかどうかは、カウンターの範囲と現在の画面の動作によって異なります。アプリの再起動、サーバーの切り替え、既存のサブスクリプションの更新も、確実なリセット方法とはみなせません。

現在のセッションの数値と過去の累計値は分けて記録します。画面に現在の接続範囲が明示されている場合は、その接続の開始時点を基準にします。項目ごとの累計が表示されている場合、それを現在の接続で発生した通信量として扱うことはできません。開始時点が画面に表示されない場合は、今日や今月、クライアントの購入日からの集計だと推測せず、前後の差分を確認するのが確実です。

• 手動で消去する：Dataの現在の画面に消去またはリセット操作がある場合は、確認メッセージを読み、対象範囲を確かめてから実行します。明確に消去されたカウンターだけを新しい開始値として扱ってください。
• 項目を削除する：サーバーを削除して作り直すと、統計の分類が変わることがあります。日常的なリセット方法には適さず、継続した比較も難しくなります。
• 再接続する：セッション値と累計値がそれぞれどう変化するかを確認し、一方がゼロになったからといって、もう一方も消去されたと判断しないでください。
• 定期的に確認する：週単位や月単位で記録する場合は、日付、開始値、終了値を自分で保存します。Dataが請求期間に合わせて自動リセットされると想定しないでください。

たとえば、観察開始時のダウンロード累計が120 MB、終了時が138 MBだったとします。同じ項目・同じ集計範囲で、途中にリセットがなければ、この間のダウンロード増分は18 MBです。数値は計算方法を示す例であり、実測値ではありません。途中で項目を切り替えたり記録を消去したりした場合、2つの数値を有効な差分として比較できません。

システムのモバイルデータ通信量と一致しない場合に確認する4項目

iPhoneまたはiPadの「設定」で「モバイル通信」を開くと、システムが集計したモバイルデータ通信量を確認できます。この画面とShadowrocketのDataでは、観察する範囲が異なります。前者はモバイル通信の使用量、後者はアプリが処理し、該当する範囲に分類したデータを示します。また、システムの「現在までの合計」は通信事業者の請求期間と同じとは限りません。画面下部で統計情報がリセットされた日時を確認してください。

プロキシプロトコルでは、接続の確立やセッションの維持にデータのやり取りが必要です。そのため、実際の通信量はWebページのファイルサイズや添付ファイルの表示サイズと一致するとは限りません。接続の再利用、失敗時の再試行、キャッシュも、操作ごとの増分に影響します。Dataがシステムより少し多い、または少ないというだけで、二重請求や統計の不具合と判断しないでください。まずネットワーク、期間、集計範囲をそろえて比較します。

60秒間の観察で継続的な通信を確認する

以下の手順はカウンターの変化を観察するためのもので、速度測定ではありません。利用中のサービス事業者やサブスクリプションを変更する必要もありません。テスト前に現在の設定を保存し、明らかなバックグラウンドダウンロードを一時停止してください。同じ観察中にネットワーク、サーバー、モードを切り替えないようにします。Settings → On Demandを設定している場合は、自動接続が発生するか記録します。自動再接続を手動テストの結果と取り違えないためです。

1. 環境を記録する：時刻、Wi-Fiまたはモバイル通信、Global Routing、現在のConfig、サーバー項目を書き留めます。
2. 開始値を記録する：Dataを開き、対象項目のアップロード・ダウンロード累計をそれぞれ記録します。アプリ別表示がある場合は、対象アプリの開始値も記録します。
3. アイドル状態で観察する：60秒間、操作せずに待ち、終了値を記録します。この観察で、バックグラウンド接続やセッション維持による基準の通信量を確認します。
4. 1つの操作を行う：次に60秒間観察し、特定のページを1つだけ開くか、キャッシュされていないコンテンツを1つ読み込みます。同じカウンターを記録してください。
5. 結果を確認する：2回の観察それぞれの増分を計算し、接続記録から新たな通信が想定した宛先によるものか確認します。テストを繰り返すときは、ほかの条件を変えないでください。

キャッシュからページを読み込んだ場合、通信量の増分はごく小さいことがあります。動画やWebページが先読みされている場合は、表示を止めたあともしばらく増加することがあります。アップロードが継続して増える場合は、増加方向だけで異常と判断せず、送信中の添付ファイル、写真の同期、ほかのバックグラウンド処理を確認してください。転送カウンターから分かるのはデータのやり取りがあったことまでで、目的のコンテンツが正常に読み込まれたことを単独で証明するものではありません。