ShadowrocketのData画面で確認できるのは、クライアントが記録した通信量であり、サービス提供元のプラン利用明細ではありません。サーバー設定が済んでいる場合は、まずアップロード・ダウンロード・累計値の違いを確認し、次にサーバー別とアプリ別の通信状況を見ます。最後に、操作前後の差分から通信の振り分けが想定どおりか確認します。集計開始の目安やバックグラウンド通信、数値が一致しない場合の確認手順も説明します。
1. 通信量と通信速度を区別する
Data画面の数値は、すでに転送されたデータ量を示します。アップロードはデバイスから外部へ送信したデータ、ダウンロードは外部からデバイスへ受信したデータです。Webページを開くと、リクエストの送信でアップロードが発生し、テキストや画像、動画の受信でダウンロードが発生します。写真をアップロードすると、通常はアップロード量が大きくなります。ダウンロードが中心の場合でも、接続やリクエスト、応答確認にデータを送るため、アップロードがゼロとは限りません。
まず数値の後ろにある単位を確認し、そのうえで数値の大きさを見ます。KB、MB、GBはデータ量を表し、「/秒」などの単位が付く場合は速度を表します。累計ダウンロード量が多くても、確認対象の期間に受信したデータが多いことを示すだけです。現在の速度は判断できず、Connectivity Testの接続確認結果の代わりにもなりません。
通信量の記録だけでは、アクセスの成功までは分かりません。リクエストの送信後に名前解決やハンドシェイク、接続先からの応答に問題が起きて、アクセスに失敗することがあります。一方、ローカルキャッシュからページが表示された場合、新たに発生する通信量は少ないことがあります。Dataの数値は、実際のアクセス結果とあわせて判断してください。
2. サーバー別とアプリ別で分かること
サーバー別表示では、対象のサーバー項目が集計範囲内でどれだけの通信を処理したかを確認できます。アプリ別表示では、どのアプリの通信として識別されたかを確認できます。同じネットワーク通信を異なる視点から見たものであり、2つの数値を足してプランの利用量とすることはできません。
| 確認する視点 | 判断できること | それだけでは判断できないこと |
|---|---|---|
| サーバー別 | サーバー項目ごとの累計量または今回の観察期間中の増加量 | すべてのアプリがそのサーバーを使用したこと |
| アプリ別 | 識別されたアプリごとの通信量の内訳や増加 | そのアプリのすべてのリクエストが同じ経路を通ったこと |
| アップロードとダウンロード | 送信量と受信量の違い | リアルタイムの帯域幅、遅延、プランの残量 |
アプリの識別は、システムから提供される情報や現在の統計機能にも左右されます。どのアプリにも明確に割り当てられない記録があっても、すぐに未知のアプリや異常なプログラムだと判断しないでください。1つのアプリが複数のドメインにアクセスしたり、直接接続とプロキシ経由のリクエストを同時に行ったりすることもあります。そのため、「アプリに通信量がある」ことと「特定のサーバーに通信量がある」ことは、必ずしも一対一で対応しません。
まとめ：同じ時間帯で2つの見方を照合する
サーバーと対象アプリの現在値を記録してから、アプリを1つだけ操作します。同じ時間帯の増加量を比べてください。サーバーの過去からの累計値と、アプリで直近に発生した少量の通信を比べないようにします。
3. 集計開始の目安と、プランの明細との違い
通信量が集計されるのは、対象の通信がShadowrocketで処理され、記録された場合です。アプリのインストール日、購入日、サブスクリプションの追加日は、Dataの現在値の集計開始時点とは限りません。また、すべての項目が「画面を開いてからの通信量」を示すわけではありません。現在の接続に関するデータと、保持されている累計記録は分けて確認してください。
集計開始の目安を確認するときは、現在の画面に期間、接続時間、リセット状態が明示されているかを優先して見てください。期間が明記されていない数値を「今日の通信量」「今月の通信量」と呼ぶのは避けましょう。接続を切った後に数値が保持されるかどうかは、該当項目の実際の変化で確認します。再接続のたびに過去の記録がすべて消えるとは限りません。
- 一定時間のアクセスを測る場合：アクセス前に数値と時刻を記録し、アクセス後にも記録して、差分で観察区間を設定します。
- サーバーを切り替えた場合：切り替え前後の記録をそれぞれ残し、以前のサーバーの累計値を現在のサーバーで今回使った量として扱わないでください。
- 削除やリセットを実行した場合：操作した時刻を新しい比較の起点として記録し、リセット前の累計値との差をそのまま計算しないでください。
- 残りの利用枠を確認する場合：サービス提供元の利用状況ページで確認してください。請求期間や通信量の計算方法は、サービス提供元の案内に従います。
クライアントとサービス提供元では、異なる地点で通信量を集計している場合があります。プロトコルのオーバーヘッド、統計の更新間隔、通信量の倍率、請求期間などにより、表示が一致しないことがあります。また、デバイスのモバイルデータ通信量は別の基準で集計され、Shadowrocketが処理していないシステム通信を含む場合があります。集計範囲を確認せずに、3つの画面の数値を相互に置き換えないでください。
4. 5ステップで通信量を確認する
以下の手順では、サーバー設定の変更やサブスクリプションの再追加は必要ありません。すでにある設定を使ってください。サブスクリプションをまだお持ちでない場合は、サービス提供元から入手してください。テストでは、Safariでキャッシュされていないページを開くなど、目的を1つに絞った操作を行います。動画の再生、アプリの更新、大量の写真の同期などを同時に行わないでください。
-
接続を確認
Homeを開き、SERVER一覧で選択中のサーバーを確認します。画面上部の接続スイッチをオンにしてからConnectivity Testを実行してください。テスト結果は接続性を判断する手がかりです。対象のページにも実際にアクセスしてください。
-
現在のモードを確認
Home → Global Routingを開き、現在の設定がConfig、Proxy、Direct、Sceneのどれかを記録します。Configを使用している場合は、Configで有効な設定も確認してください。テストの途中で設定を切り替えないようにします。
-
開始時の数値を記録
Dataを開き、対象サーバーと対象アプリのアップロード・ダウンロードの数値と時刻をそれぞれ記録します。他のアプリでのダウンロードはいったん止めてください。バックグラウンド同期が続いている可能性にも注意します。
-
アクセスを実行
Safariに戻ってページに一度アクセスし、開始時刻と終了時刻を記録します。Wi-Fi、モバイル通信、サーバーを同時に切り替えると、通信量の変化を説明しにくくなります。
-
増加量を比較
Dataに戻り、数値が更新されるのを待ってから同じ項目を記録します。後の値から前の値を引き、アクセスの成否、現在のルーティング設定、リクエストの記録もあわせて確認します。
以下は差分計算の例であり、実測値や性能を保証するものではありません。単位をそろえてください。画面の数値が丸められている場合、通信量の少ないアクセスでは変化が見えにくいことがあります。記録されていないとすぐに判断せず、観察時間を延ばしてください。
| 項目 | アクセス前 | アクセス後 | 今回の増加量 |
|---|---|---|---|
| サーバーのダウンロード | 100 MB | 120 MB | 20 MB |
| サーバーのアップロード | 10 MB | 11 MB | 1 MB |
5. Global Routingで通信の振り分けを確認する
Dataは結果を判断する手がかりで、通信の処理方法はGlobal Routingと現在の設定によって決まります。サーバーの数値が増えたかどうかを見る前に、現在のルーティング設定を確認してください。特に、Proxyで通信量を確認しただけで、Configのルールが適用されたと判断しないでください。
Config
推奨現在の設定にあるルールに基づいて経路を選択します。振り分けを確認するときは、対象のリクエスト、適用されたルール、最終的なポリシーをあわせて確認してください。どのルールにも一致しないリクエストが必ず直接接続になるとは限りません。
用途：既存の設定で想定どおりに通信が振り分けられるか確認
Proxy
処理対象の通信をプロキシ経由にします。接続性を比較する際に使えますが、Configにある特定のDOMAIN-SUFFIXやIP-CIDRのルールが有効であることを証明するものではありません。
用途：サーバーの問題とルールの問題を一時的に切り分ける
Direct
直接接続を使用します。この設定ではサーバー経由の通信量が増えないことがあり、サーバーの数値がゼロでも接続障害とは限りません。
用途：対象へのアクセスを直接接続で比較
Sceneを使用している場合は、現在のシーンに対応する設定と適用条件を先に確認してください。SceneをProxyまたはDirectと常に同じ経路になる別の選択肢として扱わないでください。比較できるように、テスト前後で同じシーンを維持します。
Configではルールの順序も重要です。DOMAIN-SUFFIXはドメインのサフィックス、GEOIPはIPアドレスの地理データベース、IP-CIDRはアドレス範囲に基づいて照合され、FINALはそれまでに一致しなかったリクエストを処理します。最終的な接続先は、アプリ名ではなく、一致したルールで指定されたポリシーによって決まります。
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY以下はルール構文の説明例です。example.comとそのサブドメインはDIRECTに一致し、それ以外はFINALによってPROXYに送られます。テストの前に、設定が参照するポリシーに対応していることを確認してください。通信量を見るために、既存の設定をそのまま上書きしないでください。Webページでは他のドメインからもリソースを読み込む場合があるため、メインのドメインが直接接続でも、一部の通信がプロキシ経由になることがあります。
まとめ：通信量の増加から分かるのはデータが通過したこと
対象のリクエストが想定したルールに一致したか確認するには、同じアクセスのリクエスト記録で対象、適用ルール、最終ポリシーを照合し、Dataの増加量を補助的に確認します。ページ全体の合計値だけで、リクエストごとの経路を判断しないでください。
6. 数値に気になる点がある場合の確認方法
設定を変更する前に、まず状況を記録してください。観察時刻、ネットワークの種類、Global Routingの設定、アクセス先を記録すると、何度も再接続するより原因を特定しやすくなります。一度に変更する条件は1つにし、アクセス後にDataを記録し直して、複数の変更の影響が混ざらないようにします。
Webページを開けるのに、サーバーの通信量が増えないのはなぜ？
まずHome → Global RoutingがDirectになっていないか確認し、次にConfigで対象がDIRECTに一致しているか確認します。その後、キャッシュされていないコンテンツに再度アクセスし、Dataの更新を待ちます。キャッシュからの表示、単位の丸め、確認対象のサーバー項目の間違いなどにより、増加が見えにくい場合があります。
操作していないのに通信量が増えるのはなぜ？
クラウド同期、メディア再生、アプリの更新を一時停止し、アプリ別の増加量を確認します。次にSettings → On Demandが有効か、またどの条件で動作するかを確認し、自動的に接続が開始される可能性がないか調べます。Homeに戻って現在の接続状態も確認してください。以前にスイッチをオフにしたことだけで判断しないようにします。
アプリとサーバーの数値が一致しないのはなぜ？
観察の開始時刻と終了時刻をそろえ、他のアプリの動作を止めてから比較し直してください。対象アプリが直接接続とプロキシ経由のリクエストを同時に発生させたり、サーバーが他のアプリの通信を処理したりする場合があります。アプリの識別範囲や数値の丸めも影響するため、2つの累計値が一致するとは限りません。
サービス提供元の利用量がDataより多い場合は？
まずプランの請求期間をそろえ、サービス提供元が案内している倍率や更新の遅れ、同じアカウントを使う他のデバイスの利用状況を確認します。Dataはクライアント上で通信を確認するためのもので、残りの利用枠はサービス提供元の明細を基準にしてください。問い合わせ時にサブスクリプションのリンクや認証情報を添付しないでください。
最後に、確認結果を「現在の接続」「現在のルーティング設定」「アクセス前後の差分」「対象リクエストの最終ポリシー」の4項目にまとめます。Connectivity Testと実際のアクセスがどちらも失敗する場合は、まずネットワークまたはサーバーへの接続を確認してください。アクセスは正常でも経路が想定と異なる場合は、Configのルール順を確認します。Dataは確認手順の一部であり、それだけで障害の原因を特定できるものではありません。