この記事は、Shadowrocketに自分のサブスクリプションを追加済みで、通信の経路を確認したい方向けです。まずサーバー別の集計とアプリ別の帰属を区別し、統計を確認する時間帯を固定します。そのうえで、1回のリクエスト、ルールの一致記録、通信量の増加を照合します。Dataの累積量はリアルタイムの速度ではなく、サービス提供元の請求明細の代わりにもなりません。アプリへの帰属範囲は、実際の画面とシステムが提供する情報に応じて異なります。
1. Dataの数値は集計範囲を確認する
Dataを開いたら、最も大きな数値だけを見るのではなく、まず各項目がサーバー、接続先、アプリのどれを示すのか、数値がアップロード・ダウンロード・合計のどれなのか、いつからの集計なのかを確認します。どちらもMB表示でも、集計対象や開始・終了時刻が異なれば、数値が一致するとは限りません。グループ分け、項目、リセット方法は実際のアプリ画面で確認してください。
通常、アップロードはデバイスから送信したデータ、ダウンロードはデバイスが受信したデータを指します。Webページを見るときもリクエストや接続のネゴシエーション、確認情報が送信されるため、アップロード量がゼロでなくても、ファイルを送信しているとは限りません。累積通信量は一定期間に転送したデータ量で、速度はKB/sのように時間あたりの値です。累積量の20 MBを「現在の速度が20 MB」と捉えるのは誤りです。
操作中に発生した通信量を確認するには、終了時の値から開始時の値を差し引きます。累積合計どうしを比べるのではありません。途中で統計をリセットしたり、集計範囲を変えたり、接続を確立し直したりした場合は、基準値を取り直してください。アプリ内のカウンター、システムのモバイルデータ使用量、サービス提供元の請求明細は集計範囲がそれぞれ異なるため、数値が一致しないだけで異常とは判断できません。
2. サーバー別は出口、アプリ別は発生元を見る
サーバー別の集計で分かるのは、「どのサーバー項目を経由してデータが処理されたか」です。複数のアプリが同じサーバーを使えば、通信量は合算されます。ひとつのアプリでも、ルールによって異なる接続先や出口を使うことがあります。そのため、サーバーの通信量が増えたからといって、特定のアプリのリクエストがすべてそのサーバーを経由したとは限りません。
アプリ別の表示は、「どのアプリが通信を発生させたか」を示そうとするものです。ただし、アプリの識別情報とドメイン名は同じではありません。ひとつのアプリがコンテンツ、画像、ログイン、プッシュ通知など複数のドメインに接続することも、同じドメインに複数のアプリが接続することもあります。特定の接続先ドメインの累積通信量を、あるアプリの総使用量と見なすことはできません。
特にiPhoneやiPadでは、VPNトンネルが取得するパケット情報は、システムのプロセス情報全体と同じではありません。現在のData画面にアプリの帰属項目がなければ、サーバー名からアプリ別のランキングを推定できません。識別不能または帰属先不明の記録がある場合は、不確実な情報として扱ってください。モバイル通信でのアプリ別使用量を確認するには、システムのSettings → Cellularを開き、システム側の統計期間も確認します。この数値にはWi-Fiでのアプリ通信量は含まれません。
| 確認対象 | 分かること | それだけでは証明できないこと |
|---|---|---|
| サーバー項目 | 現在の時間帯における、その項目の通信量の変化 | 特定アプリのすべてのリクエストがこのサーバーを経由したこと |
| アプリの帰属情報 | 識別できる範囲での通信元 | デバイス上のすべてのアプリの通信が完全に特定されていること |
| 接続先ドメインまたはIPアドレス | リクエストの接続先 | リクエストが特定のアプリから発生したこと |
| システムのモバイルデータ使用量 | システムの統計期間中に使用したモバイルデータ量 | 同じアプリがWi-Fiで使用した通信量 |
3. 観察時間を固定し、再現可能な通信テストを行う
テスト前にHomeを開き、接続が確立していることを確認します。次にGlobal Routingの現在の選択項目と、Configで有効になっている構成ファイルを記録します。この記事では、すでに利用しているサーバーとサブスクリプションがあることを前提とします。統計を見るために新たな接続サービスを用意する必要はありません。前後を比較しやすいよう、テスト中はサブスクリプションを更新したり、サーバーを切り替えたりしないでください。
- 他の通信を減らす：大容量ファイルの転送、動画の再生、クラウド同期を一時停止します。他のアプリでの操作も控えますが、これだけでバックグラウンド通信がすべてなくなるとは限りません。
- 開始時の値を記録：Dataで対象サーバーのアップロード・ダウンロード累積値と時刻を書き留めます。以前の記録は残しておけばよく、テストのたびに統計をすべて消去する必要はありません。
- 操作をひとつに絞る：アプリをひとつだけ開き、既知のページにアクセスするか、明確な操作を1回行います。複数のページを同時に更新せず、約60秒観察します。
- 終了時の値を記録：Dataに戻り、同じ項目を同じ集計範囲で確認します。アップロードとダウンロードの増加量をそれぞれ計算してください。
- リクエストを照合：利用できる接続記録で、接続先ドメイン、一致したルール、出口の情報を確認します。詳細が不足している場合は結論を控えめにし、通信量の増加だけを根拠にしないでください。
- もう一度テスト：設定を変えずに再テストします。2回目はキャッシュが使われる場合があるため、1回目とバイト数が完全に一致する必要はありません。
設定を比較する場合は、一度に変更する条件をひとつにします。たとえばサーバーは変えず、Global RoutingをProxyからConfigに切り替えてから、テスト接続を確立し直します。サーバー、DNS、ルールを同時に変更すると、数値が変わっても原因を特定できません。
4. 通信量の増加とルールの一致を照合する
Home → Global RoutingにあるProxy、Direct、Config、Sceneは、それぞれ異なるルーティング設定です。Proxyはプロキシ経由の経路との比較、Directは直接接続との比較に使えます。Configでは、現在の構成にあるルールに従って接続先が判断されます。Sceneは選択中のシーン設定に基づいて判断する必要があり、常にプロキシ経由、または常に直接接続になる設定とは限りません。
ルールによる振り分けを確認するには、まずConfigを使い、Configで現在有効なファイルを確認します。通常、ルールは上から順に評価され、先に一致した項目が結果に影響します。FINALは最後のフォールバックです。エディターにDOMAIN-SUFFIXが表示されているだけでは、今回の接続にそのルールが一致したことも、他の一致候補より先に評価されたことも証明できません。
テスト前に記録
- 接続画面
- Home
- ルーティング画面
- Home → Global Routing
- ルーティング設定
- Config
- 構成の確認
- Configで現在有効なファイル
記憶に頼らず、実際に選択されている状態を記録します。
ルール例の意味
- DOMAIN-SUFFIX
- example.com,PROXY
- IP-CIDR
- 192.0.2.0/24,DIRECT,no-resolve
- FINAL
- DIRECT
- 評価順序
- 上から順に評価し、一致したルールのポリシーを適用
この例では予約ドメインと文書用IPアドレス範囲を使っています。構文の説明用であり、テスト先ではありません。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,DIRECT上の例では、example.comとそのサブドメインにPROXYが適用され、文書用IPアドレス範囲にはDIRECTが適用されます。no-resolveは、このIPルールのために追加のドメイン解決を行わないことを示します。それ以外のリクエストは最終的にDIRECTになります。これはルールの一部にすぎず、完全な構成の代わりにはなりません。実際に使う際は、現在の構成で利用できるポリシー名と目的に合っているか確認してください。
確認の基本：1件のリクエストに対して証拠をそろえる
接続先をPROXY経由にする想定なら、そのリクエストに一致したルール、実際の出口、対応するサーバーの通信量増加をあわせて確認します。累積値が増えただけでリクエストとの対応が分からない場合は、アプリをひとつに絞って再テストし、すぐにルール全体を変更しないでください。
5. 数値が想定と異なる理由
最も多い原因はルールの不具合ではなく、統計の集計範囲の違いです。デバイス側は特定の処理段階で計測する一方、サービス提供元はサーバー側の独自基準で課金することがあります。通信のカプセル化、接続のネゴシエーション、再送、上下方向の課金方法、時間帯も差の要因になります。HTTPSではTCP 443、HTTP/3ではUDP 443がよく使われますが、ポート番号が同じでも通信元アプリが同じとは限らず、すべてのリクエストが同じ方式で転送されるわけでもありません。
- ページキャッシュ：ページがローカルキャッシュから表示された場合、更新確認のリクエストだけが発生することがあります。画面が変わっても、すべての内容をダウンロードし直したとは限りません。
- バックグラウンド動作：通知、同期、その他の接続により、テスト対象のアプリを操作していない間もサーバーの累積値が増えることがあります。
- 直接接続の通信：DIRECTのリクエストは、プロキシサーバーの項目に加算されるとは限りません。他の集計に表示されるかどうかは、現在の画面の集計範囲を確認してください。
- 既存の長時間接続が以前の経路を使い続ける：ルールを切り替えても、確立済みの接続は元の経路を使い続けることがあります。テスト操作を終了し、新たに接続してから新しいルールを確認してください。
- カウンターと更新：表示の丸め、更新間隔、リセット、統計期間の変更は、少量の通信を比較するときに影響します。差を計算する前に、これらの要因を確認してください。
- サーバー項目の変更：自分のサブスクリプションを更新すると、サーバー名、アドレス、グループが変わることがあります。更新前後で名前が同じ記録でも、ひと続きのデータとして比較できるとは限りません。
On Demandも観察時間に影響します。テスト中に自動切断または再接続が発生した場合は、Settings → On Demandで起動条件を確認し、実際の接続状態を記録してください。On Demandが管理するのは接続動作です。特定のリクエストがPROXYまたはDIRECTに一致したとは判断できません。ルーティングの確認にはGlobal Routingとリクエスト記録を使います。
6. よくある数値の疑問と確認手順
アプリを開いたのに、サーバーの通信量が増えないのはなぜ？
まずページがキャッシュから表示されていないか確認し、次にHomeで接続状態とGlobal Routingを確認します。Directが選ばれている場合や、Configのルールで接続先がDIRECTに振り分けられている場合は、プロキシサーバーの通信量が増えなくても正常です。ネットワークを使う操作をもう一度行い、リクエストの接続先と出口を確認してください。
アプリをすべて閉じたのにDataの数値が増え続けます。ルールが間違っていますか？
まず他の通信を停止し、連続する60秒の時間帯を2回分記録して増加量を比べます。次にバックグラウンド接続や、まだ転送中の長時間接続がないか確認します。前面で操作していないことだけを理由に異常とは判断できません。ルールを変更する前に接続先と通信を特定してください。
アプリ別の数値を合計しても、サーバーの合計と一致しないのはなぜ？
まず時間帯、ネットワークの種類、アップロード・ダウンロードの集計範囲をそろえます。次にアプリの帰属が完全か、帰属先不明の記録があるか、DIRECTの通信が含まれているかを確認してください。システムのモバイルデータ統計とDataを比較する場合、両者が一致するとは限りません。差分を特定のアプリにすべて割り当てることもできません。
ルールを変更したのに、統計上は以前のサーバーを使っているように見えるのはなぜ？
まずConfigで変更後のファイルが有効になっていることを確認し、次にHome → Global RoutingでConfigを選びます。既存の接続を終了してから再試行してください。それでも想定と異なる場合は、先に評価されるルールとFINALを確認します。必要に応じて再接続しますが、接続前後の累積値を混ぜないよう、先にテストの基準値を保存してください。
調査記録には、テスト時刻、ネットワークの種類、Global Routingの選択、使用中の構成、対象リクエスト、アップロード・ダウンロードの増加量を含めます。詳しく確認するにはトラブルシューティングガイドで接続とルールを確認するか、用語ガイドでポリシーのキーワードを確認してください。Dataは傾向の把握や仮説の検証に役立ちます。最終的な振り分けの判断は、具体的なリクエストと実際の出口に基づいて行ってください。