この記事の要点

DataはShadowrocketが記録した通信量を確認する機能です。携帯電話会社の請求データではなく、特定のWebサイトにどのルールが適用されたかを単独で証明するものでもありません。利用中のサービスやサブスクリプションがあり、接続できている方向けに、サーバー別とアプリ別の集計の違いと、「基準値を記録・リクエストを送信・増分を確認・ルールを照合」という確認手順を説明します。Appleプラットフォームや画面によって集計項目は異なる場合があるため、現在の画面に表示されている内容に基づいて判断してください。

1. 累計通信量・リアルタイム速度・課金対象の通信量を区別する

ShadowrocketはApp Storeで配信されているAppleプラットフォーム向けの有料クライアントで、主にiPhoneとiPadで利用できます。App Storeの製品ページで、デベロッパのShadow Launch Technology LimitedとアプリID 932747118を確認できます。システム要件はApp Storeのページに記載された内容をご確認ください。Dataの数値はクライアント上で観測されたものであり、通信事業者や利用中のサービスの課金記録の代わりにはなりません。

各項目を確認するときは、名称、単位、集計範囲を先に確認します。アップロードは通常、デバイスから送信したデータ、ダウンロードはデバイスが受信したデータを指します。いずれもデバイス側から見た方向で、リモートサーバー側の方向ではありません。毎秒の単位が付いた数値は通信速度、バイト単位のみの数値はデータ量です。画面に「今回の接続」や対象期間が明記されていない場合、累計値を当日の通信量と解釈しないでください。

8 bit
1 Bと同じです。小文字のbと大文字のBは意味が異なります
B/s
1秒あたりのバイト数です。通信速度を示し、累計データ量ではありません
443
HTTPSでよく使われるポートです。ポート番号だけではPROXY経由かどうかは判断できません

接続がアイドル状態でも、累計値が増えることがあります。バックグラウンド同期、通知、DNSクエリ、接続維持、再試行などでデータが発生する場合があります。ただし、リクエストの詳細がなければ、この数値だけで原因を特定することはできません。逆に、Webページが表示されてもダウンロード量の増加がごく小さい場合は、ローカルキャッシュが使われた可能性があります。

2. サーバー別の数値:出線ごとの集計を確認する。端末全体の通信量ではない

サーバー別に確認するときは、まずHomeで現在選択しているサーバーと照合してください。同じ名前でも接続設定が同じとは限りません。名前の変更、サーバーの切り替え、既存サブスクリプションの更新後に記録を比較する場合は、アドレス、ポート、実際に選択された接続先も確認します。サーバー別の数値が示すのは「クライアントがこの出線に集計した通信量」であり、「端末上の全アプリが使った通信量」ではありません。

確認対象判断できることそのままでは判断できないこと
特定サーバーのアップロード増分対象の集計範囲で、この出線へ送信したデータが増えた増加分のすべてが前面で使用中のアプリから発生した
特定サーバーのダウンロード増分対象の集計範囲で、この出線を通じて受信したデータが増えた増加量が特定ファイルの公称サイズと一致する
以前使っていたサーバーに累計値が残っている画面にその項目の過去の統計値が保持されている現在のリクエストも以前のサーバーを使用している
サーバーの数値に変化がない観察した期間中、その項目に表示上の増分がなかったリクエストが必ずDIRECTを通った、または接続が必ず失敗した

リクエストがDIRECTを通る場合、プロキシサーバーを経由しないため、特定のプロキシサーバーの数値を直接接続の総量として扱うべきではありません。また、画面の合計値と個別サーバーの集計範囲が異なる場合があります。比較や合算をする前に、対象期間、絞り込み条件、リセット時点が一致していることを確認してください。

3. アプリ別の数値:識別できる範囲を確認してから通信量を判断する

アプリ別とサーバー別は異なる集計方法です。前者は「どのアプリからデータが発生したか」、後者は「どの出線を経由したか」を確認するものです。同じアプリから複数のドメインへアクセスしたり、一部のリクエストは直接接続、別のリクエストはプロキシ経由になったりするため、アプリの累計量が特定サーバーの累計量と一致するとは限りません。

特にiPhoneやiPadでは、トンネルから見えるネットワーク通信をプロセスの完全な識別情報と同一視できません。現在のData画面にアプリ一覧がない場合、汎用的な「アプリ別」スイッチを探す必要はありません。アプリ別の集計が表示される場合も、画面上で実際に識別された範囲に基づいて判断してください。識別できない記録や帰属先が不明な記録を、直前に開いたアプリに割り当てないでください。

特定のアプリがモバイル通信を使ったか確認する場合は、システムの「設定 → モバイル通信」で該当アプリの統計も確認し、集計期間を照合してください。システムのモバイル通信統計には同じ期間のWi-Fi通信量は含まれません。Dataはその時点の接続状況と画面上の集計方法を踏まえて解釈する必要があり、両者は同じ請求明細ではありません。

4. PROXYかDIRECTかを判断する:まずルーティングモードを確認し、次にルールの適用結果を見る

Dataは通信結果を表示し、Global Routingはリクエストのルーティング方法を決めます。ルールを調べるときは、まずHome → Global Routingで現在のモードを確認し、次にConfigで実際に有効な設定を確認します。ProxyとDirectはそれぞれ、全体をプロキシ経由にする場合と直接接続にする場合の基本モードです。Configでは設定内のルールに従って通信を振り分けます。Sceneは選択したシーンの具体的な設定を確認してください。名前だけを見てConfigと同じ動作だと判断しないでください。

リクエストの発生 ルーティングモード ルールの照合 実際の出線 集計

以下はルールの順序を説明するための最小限の例であり、完全な設定ではありません。example.comは例示用のドメインです。実際に確認する対象の代わりには使えません。PROXYで転送するには、利用可能なプロキシ出線が設定済みである必要があります。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,DIRECT

ルールの例を読む

DOMAIN-SUFFIX
example.com,PROXY:このドメインとサブドメインに一致します。
IP-CIDR
192.168.0.0/16,DIRECT,no-resolve:該当するアドレス範囲に一致します。このルールではドメイン名を自動的に名前解決しません。
FINAL
DIRECT:それより前のルールに一致しない場合、直接接続します。

ルールは上から順に照合されます。この例は説明用です。変更する前に元の設定を保存してください。

動作条件を確認する

Home → Global Routing
ルールをテストするときはConfigを使用し、Sceneが切り替わっていないことを確認します。
Config
選択中のファイルが、テスト用ルールを含むファイルであることを確認します。
Settings → On Demand
自動接続の条件が、テスト中のトンネル状態に影響しないか確認します。

On Demandは条件に応じて接続を処理する機能であり、WebサイトがPROXYまたはDIRECTを使った証明にはなりません。

より確かな根拠は、対象リクエストに対応するルールと実際の出線記録です。現在の画面で接続やリクエストの詳細を確認できる場合は、ドメイン、接続先アドレス、時刻から同じリクエストを特定し、適用されたルールとポリシーを照合します。サーバーのカウンター増加は補助的な確認にとどまります。同じ時間帯にほかのリクエストもそのサーバーを使っている可能性があるためです。

5. 前後の差分で再確認できる通信テストを行う

過去の統計をすべて消去する必要はありません。履歴を残したままテスト前後の数値を記録すれば、参考データを誤って削除せずに済み、画面にリセットボタンがあるかどうかにも左右されません。以下の手順では、利用者自身がすでにアクセスできる対象だけを使います。サービスを変更したり、新たに追加したりする必要はありません。

  1. 環境を固定する:Wi-Fiまたはモバイル通信のどちらかを選び、テスト中は切り替えません。進行中の大容量転送を一時停止し、Homeで現在のサーバーとGlobal Routingのモードを記録します。
  2. 基準値を記録する:Dataを開き、対象サーバーのアップロード・ダウンロードの数値と単位を控えます。アプリ別の表示がある場合は、該当アプリの数値も記録します。約30秒待ち、アイドル状態でも目立った増加があるか確認します。
  3. 操作は1つだけ行う:対象のWebページを1つ開くか、自分がすでに持っているテストファイルを読み込みます。複数のテストを同時に実行せず、開始時刻と終了時刻を記録し、リダイレクト後のドメインにも注意してください。
  4. 増分を確認する:ページの統計が更新されるまで待ち、終了時の数値から開始時の数値を引きます。表示精度が低い場合、小さなリクエストはすぐに数値へ反映されないことがあります。直ちに通信量ゼロと判断しないでください。
  5. 複数の情報を照合する:対象リクエストに適用されたルール、実際の出線、カウンターの増分をあわせて判断します。設定を変更する必要がある場合は条件を1つだけ変更してテストを繰り返し、終了後に元の設定へ戻してください。

6. よくある数値の疑問と対処方法

Webページは開けるのにサーバーの通信量が増えません。プロキシを経由していないのでしょうか?

まずページがキャッシュから表示されていないか確認し、次にHome → Global RoutingとConfigで有効なルールを確認します。実際にDIRECTが適用された場合、プロキシサーバーの数値が増えないのは正常です。PROXYが適用された場合は、別のサーバー項目を見ていないか、数値がまだ更新されていないか、リクエストが実際に再送信されたかを確認してください。

Dataの数値がダウンロードしたファイルのサイズより大きいのはなぜですか?

ほかの通信を一時停止し、前後の差分を使って再テストしてください。ファイルの公称サイズが示すのはファイルの内容だけですが、統計にはほかのリクエスト、リクエストヘッダー、接続維持、再試行などが含まれる場合があります。どの階層の通信が集計されるかは画面の定義に従ってください。固定比率を使ってファイルサイズを逆算することはできません。

サーバーを切り替えた後も以前のサーバーに数値が残っています。削除すべきですか?

まず累計値と新たな増分を区別します。以前の項目の数値を記録し、少し待ってから対象を明確にしたリクエストを1回送信し、数値が変化するか確認してください。古い数値に増分がなければ、通常は過去の参考値です。画面を「ゼロ」にする目的だけで、既存のサーバーや設定を削除しないでください。

システムのモバイル通信統計とDataの数値が大きく異なります。通信プランの使用量はどちらを基準にすればよいですか?

通信プランの使用量は、通信事業者の課金記録を基準にしてください。まずシステムの「設定 → モバイル通信」で集計期間を確認し、Wi-Fi通信量、リセット時刻の違い、バックグラウンド通信を考慮します。Dataはクライアントから見える通信の内訳を調べるためのもので、プランの残量を示す機能ではありません。

アプリ別の一覧に目的のアプリがありません。ドメイン別の通信量をそのアプリのものとして計上できますか?

そのように直接割り当てることはできません。複数のアプリが同じドメインを使う場合があり、Webページが第三者のリソースを読み込むこともあります。まず1つのアプリだけを使い、短い時間枠でテストを繰り返してください。それでも画面上で発生元を確認できない場合は、サーバーの増分をすべてそのアプリに割り当てず、「帰属先を特定できない」と記録してください。

7. 調査記録には集計条件を残し、機密情報を隠す

再確認できる記録には、テスト日時、ネットワークの種類、Global Routingのモード、有効なConfig、対象ドメイン、同じ項目の前後の差分を含めます。利用中のサービス提供元に状況を伝える必要がある場合は、エラーの内容と実際に適用されたポリシーも追加します。対象時間が分からない累計値だけでは、通常、個別のリクエストを特定できません。

結論は「今回のテスト時間内に、このリクエストには特定のルールが適用され、対応する出線の数値が増えた」のように記録してください。「Dataに数値があるので、すべての通信がプロキシを通った」とは判断できません。ルールの根拠と統計の根拠を分けて記録すれば、ルーティングの誤り、キャッシュの影響、バックグラウンド通信、集計範囲の違いを見分けやすくなります。