Dataは通信量の変化を確認するのに便利ですが、特定のルールに一致したか、回線の請求量が正しいかを単独で判断するものではありません。接続設定済みのiPhone・iPadユーザー向けに、アップロードとダウンロード、集計方法の違いを説明します。同じ時間幅で通信量の増分を比較し、Global Routing、Config、接続ログと照らし合わせて通信経路を確認しましょう。
1. 累積通信量とリアルタイム速度を区別する
ShadowrocketのDataの数値は、単位も含めて確認しましょう。アップロードはデバイスから送信したデータ、ダウンロードは受信したデータです。Webページを開くだけでも、ブラウザーがリクエストや接続情報を送信するため、アップロードが発生します。ダウンロード量が多くてもアップロードがゼロになるとは限らず、アップロードが増えたからといってファイルを送信中とは限りません。
容量を表すKB、MB、GBと、時間あたりの転送速度を表すKB/s、MB/sは別のものです。前者は一定期間に転送したデータ量、後者は転送速度を示します。累積値が大きいのは過去の転送量が多いということで、現在の速度が速いことの証明にはなりません。ページの読み込みが終わって速度が落ちても、累積値は自動では減りません。
上記の60秒はテスト方法の目安であり、Dataの更新間隔が一定という意味ではありません。統計が保存されるか、いつ更新されるか、どの分類が表示されるかは、デバイス上の現在の画面で確認してください。比較を始める前に時刻、単位、分類を記録し、前日の累積値と今日の1回のWebリクエストを比べないようにしましょう。
2. サーバー別とアプリ別の統計は単純に合算できない
サーバー別表示では、観察中に特定のサーバー項目のアップロード量やダウンロード量が増えたかを確認します。これは「この出力先に関連する統計に変化があったか」を示すもので、「どのアプリが通信量をすべて使ったか」を示すものではありません。複数のアプリが同じサーバーを使うこともあれば、ルーティングの切り替えにより、同じアプリの接続ごとに異なる出力先が使われることもあります。
アプリ別表示では、画面が識別し、該当する項目に分類できた通信量を確認します。Appleプラットフォームで通信元を識別するには限界があり、この表示をシステム内の全アプリを網羅する監査結果と捉えることはできません。システムサービス、バックグラウンド処理、帰属先を特定できない接続は、想定したアプリ名で表示されないことがあります。名称から推測するより、実際の分類表示を確認しましょう。
| 確認する切り口 | 判断できること | これだけでは判断できないこと |
|---|---|---|
| サーバー別 | 今回の測定中に通信量が増えたサーバー項目 | 増加分のすべてが特定の前面アプリによるもの |
| アプリ別 | 識別された通信元の項目で転送量が増えたか | そのアプリのすべてのリクエストが同じルールに一致したか |
| アップロードとダウンロード | 送信量と受信量がそれぞれどれだけ増えたか | サービス提供元の課金対象通信量とバイト単位で一致するか |
確認方法：それぞれの増分を比較し、異なる分類の数値は合算しない
まず同じ分類内でテスト前後の数値を比較し、次にもう一方の分類で変化の方向を確認します。サーバー別とアプリ別は通信を見る切り口が異なります。両方の数値を足すと重複計上になる可能性があり、合計をより正確に算出できるわけではありません。
3. 集計範囲とリセット：記録を残して基準値を決める
Data、システムの通信量、サービス提供元の請求量では、集計期間、対象範囲、プロトコルのオーバーヘッド、単位換算が異なる場合があります。同じダウンロードを確認しても、3か所の数値が完全に一致するとは限りません。特に、アプリに表示されるダウンロード量をサブスクリプションの残量とみなさないでください。利用枠や課金期間は、サービス提供元の案内で確認しましょう。
リセットは観察期間を短くするためのもので、接続を修復するために必須の操作ではありません。切断と再接続、アプリの終了、サブスクリプションの更新をしても、統計が必ずゼロになるとは限りません。現在のData画面にリセット操作がある場合は、個別項目と統計全体のどちらに適用されるかを事前に確認し、必要な記録を保存してください。アイコンの位置だけで操作範囲を判断しないようにしましょう。
- まず記録：サーバー名、アップロード量とダウンロード量、記録時刻、および今回使用するGlobal Routingの状態を保存します。
- 次に基準値を決める：過去の記録を残す場合はリセットせず、現在の数値を開始値にします。新しい観察期間を始める場合は、画面に実際に用意されているリセット操作を使います。
- 結果を確認：リセット後、対象の分類をもう一度確認します。バックグラウンド接続があると数値がすぐに増えることがあるため、長時間ゼロのままであることを期待しないでください。
- 条件をそろえる：次の測定でも同じネットワーク、同じテスト対象、同じ時間を使います。Wi-Fiとモバイル通信を切り替えた場合は、改めて測定を記録してください。
4. ルールによる振り分けを確認する：まずGlobal Routingを確認
Dataは通信量の変化を示し、ルールはリクエストの経路を決めます。互いに代用できるものではありません。HomeでGlobal Routingを確認します。Configを使っている場合に限り、現在の設定にあるルールと照らして一致結果を確認してください。ProxyまたはDirectを使っている場合は、Config内の特定のドメインルールだけで状況を説明しないようにしましょう。Sceneを使っている場合は、現在のシーンと適用中の設定を確認してからテストします。
以下はルール構文の説明例であり、既存の設定全体を置き換えるためのものではありません。例にあるPROXYは、現在の設定で実際に利用できるポリシーを指定してください。example.comは説明用ドメインのため、実際の通信の振り分けを確認する用途には使えません。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX：ドメインの末尾に基づいて一致します。同じページの画像、動画、APIが別のドメインから読み込まれることがあります。IP-CIDR：宛先IPアドレスの範囲に基づいて一致します。例のno-resolveは、このIPルールのためにドメイン名を能動的に解決しないことを示します。GEOIP：IPアドレスの地理的な割り当て先に基づいて一致します。Webサイトに表示される言語から、一致したかどうかを判断することはできません。FINAL：それ以前のルールに一致しない場合のフォールバックです。その前に別のルールが先に一致していないかも確認してください。
Configで使用中の設定とルールの順序を確認してから、新しい接続を開始します。ルール変更前に確立した長時間接続は、以前の出力先を引き続き使う場合があります。そのため、Dataを更新するだけではリクエストが再評価されるとは限りません。テスト中の処理を停止して新しいリクエストを送り、利用可能な接続ログで宛先ドメインまたはIP、一致したルール、出力先のポリシーを確認しましょう。
5. 60秒の比較テスト：増分から原因を絞り込む
テスト前に大容量通信を伴うほかの処理を一時停止し、アクセス権があり、繰り返しリクエストできる対象を選びます。Homeの接続状態とサーバー選択を変えずにDataの開始値を記録し、60秒間観察してください。サブスクリプションの更新、プロトコルの変更、ルールの修正を同時に行うと、数値が変わっても原因を特定しにくくなります。
| 数値の例 | テスト前 | テスト後 | 今回の増分 |
|---|---|---|---|
| サーバーのダウンロード量 | 120 MB | 132 MB | 12 MB |
| サーバーのアップロード量 | 8 MB | 9 MB | 1 MB |
表の数値は計算方法を示すための例であり、実測値ではありません。ダウンロード量の増分12 MBを60秒で割ると、この時間内の平均は約0.2 MB/sです。待ち時間も含むため、ダウンロード中のピーク速度とは異なります。画面の値が丸められている場合、差分も概算になり、小さなリクエストの比較には適しません。
次の手順：統計の変化と個々の接続を照合
対象サーバーの通信量が増え、テスト対象を読み込めた場合に分かるのは、「今回、そのサーバーで通信があった」ということまでです。特定ドメインの振り分けが正しいか確認するには、リクエストに適用されたルールと出力先も確認してください。数値が変わらない場合は、まずキャッシュと既存接続の影響を除外し、その後でルールや設定を確認します。
Directとプロキシ経由の通信を比較する場合は、測定を別々の回に分け、毎回基準値を設定し、変更する条件は1つだけにします。ブラウザーのキャッシュから表示されたページでは、新しいダウンロードがほとんど発生しないことがあります。再リクエストを確認できる自分のテスト用リソースを使い、プランを消費するだけの大量通信は避けてください。
6. よくある疑問と確認手順
Webページを開いていないのに、Dataの数値が増えるのはなぜ？
まず同期やメディア再生など、把握している処理を一時停止して、一定の時間幅で観察します。バックグラウンドのリクエスト、接続維持、システムサービスでも通信が発生することがあります。Settings → On Demandでオンデマンド接続を設定している場合は、現在その条件によって接続が開始していないかも確認してください。少量の増加だけで異常な通信があると判断することはできません。
Webページは開くのに、選択中のサーバーの数値が変わりません。振り分けに失敗していますか？
まずHomeでGlobal Routingとサーバーの選択を確認し、次にConfigで適用中の設定を確認します。リソースがキャッシュから読み込まれた、Direct経由でアクセスした、または別のポリシーで選択されたサーバーを使った可能性があります。スイッチを何度も切り替えるより、新しいリクエストを送り、接続ログを確認するほうが判断に役立ちます。
アプリ別リストに使用中のアプリが表示されない場合は？
アプリ名が表示されないからといって、通信していないとは限りません。同じ時間幅で全体の変化とサーバー別の増分を確認し、リクエストの宛先と時刻を照合してください。帰属先を正確に特定できない項目は不確かなまま扱い、識別できない通信を無理に特定のアプリへ割り当てないようにしましょう。
サブスクリプションの更新後に通信量の数値が変わりました。再度リセットする必要はありますか？
まずサーバー項目、ポリシーの参照先、現在の選択に変更がないか確認します。サブスクリプションの更新と統計のリセットは別の操作です。以前の記録を残したまま開始値を改めて設定すれば、テストを続けられます。項目が置き換わっている場合は、表示名が同じだからといって、更新前後の数値を同一項目の連続記録として扱わないでください。
確認が終わったら、必要なルーティング設定を元に戻し、「時刻、ネットワーク、設定、サーバー、開始値と終了値、対象リクエスト」の6項目を記録に残します。Dataで変化を確認し、接続ログで通信先を把握し、サービス提供元の情報で利用枠を確認します。それぞれの役割を分けて記録するほうが、何度もリセットするより問題を再現しやすくなります。基本操作はGlobal Routingの使い方、ドメイン名前解決の問題はDNSのトラブルシューティングをご覧ください。