Dataは通信量の変化を確認するのに便利ですが、特定のルールが適用されたことを単独で証明するものではありません。利用者がすでに契約しているサービスとサブスクリプションを使う前提で、累計通信量とリアルタイム速度、サーバー別とアプリ別の表示を解説します。ネットワーク条件を固定し、テスト前後の数値とリクエスト記録を照合して、通信の振り分けを確認します。表示される統計項目はデバイスによって異なる場合があります。実際に表示される項目に沿って操作し、アプリの識別結果をシステム通信の完全な一覧とみなさないでください。
統計の見方：アップロード・ダウンロードと速度
ShadowrocketのDataを確認するときは、数値が累計バイト数なのか、単位時間あたりの転送量なのかを最初に確認します。アップロードはデバイスから外部へ送信したデータ、ダウンロードはデバイスが受信したデータです。「ファイルを誰が作成したか」ではなく、デバイスから見た方向で区別します。Webページを開く場合も、リクエストや応答確認などの送信が必要なため、通常はアップロードが発生します。
累計値の単位は通常、KB、MB、GBなどのデータ容量です。/sが付く数値は速度を表します。累計ダウンロード量が20 MB増えても、「ダウンロード速度が20 MB/s」とは言えません。表示がバイト単位の速度で、速度測定結果がビット単位の場合、理論上は1 byte = 8 bitsです。実際に比較するときは、計測時間と単位の基準もそろえてください。
統計値は計測の開始点と対象範囲にも左右されます。接続開始、アプリの再起動、手動リセットを、同じ計測の区切りとみなさないでください。まず、ページに表示されている時間範囲やリセット状態を記録します。明確な説明がない場合は、同じページで同じテストを行った前後の差だけを比較してください。Dataのローカル計測値とサービス事業者の請求値は、異なる階層を基準にしている場合があります。プロトコルのオーバーヘッド、課金対象の通信方向、精算ルールも異なる可能性があるため、プランの残量を推定することはできません。
| 確認できる現象 | 分かること | それだけでは分からないこと |
|---|---|---|
| 累計ダウンロード量が増加 | 対象の統計範囲でデータを受信した | 対象のWebページが完全に読み込まれたこと |
| 瞬間速度がゼロ | 現在の計測時間帯に通信がほとんどない、または発生していない | サーバーが必ず利用不能であること |
| アップロード量が継続して増加 | デバイスから外部へのデータ送信が続いている | ユーザーファイルを必ずアップロードしていること |
| ローカル計測値と請求値が異なる | 両者の計測方法を確認する必要がある | どちらかの計測に必ず誤りがあること |
サーバー別の数値：出口を確認し、選択中の項目を全通信とみなさない
サーバー別の集計では、「どのサーバーの数値が変化しているか」を確認できます。Homeでサーバーを選択していることは、関連するプロキシの現在の選択状態を示すだけです。Configでは、リクエストの経路は設定ルールによって決まります。そのため、選択中のサーバーの数値がほとんど増えていなくても、すべての通信に失敗しているとは限りません。直接接続されている場合や、別のポリシーが適用されている場合もあります。
この流れは通信の振り分けを理解するためのもので、すべてのカウンターが同じ階層にあることを示すものではありません。サーバーを確認するときは、名前、アドレス、ポートを記録し、同じ名前の項目を別の出口と取り違えないようにしてください。ポートは接続パラメーターであり、統計の単位ではありません。設定のポートが443でも、ポート番号だけで実際のプロトコルを特定することはできません。
- Homeで現在の接続状態、サーバーの選択、Global Routingを確認します。
- Dataを開き、対象サーバーに表示されているアップロード量とダウンロード量を単位ごと記録します。
- 目的を明確にしたネットワーク操作を1回行い、同じ統計項目に戻って増加量を記録します。
- 増加量が予想と異なる場合は、そのリクエストに実際に適用されたポリシーやルールを確認します。すぐにサーバーを変更しないでください。
既存の接続も、よくある誤差要因です。サーバーの切り替えやルールの変更後も、確立済みの接続が新しい条件ですぐに再接続されるとは限りません。テスト時は、進行中のネットワーク処理を終了してから新しいリクエストを行います。再接続が必要な場合は、重要な通信を停止してから実施してください。切り替え後も再生が続いている動画だけを根拠に、新しいサーバーがその接続を処理しているとは判断できません。
アプリ別の数値：アプリ、ドメイン、システム通信を区別する
サーバー別は出口の視点、アプリ別は通信元の視点です。両者は別々の通信量ではないため、足し合わせることはできません。同じリクエストが、通信元と出口の両方に紐づく場合があります。アプリ別の表示では「テスト中にどの識別可能な通信元が動いたか」、サーバー別では「どの出口で通信量が変化したか」を確認できます。同じ時間帯を対象に、両方を照らし合わせてください。
iPhoneとiPadでは、トンネルから取得できる情報は、システムのバッテリー設定やモバイル通信設定に表示されるアプリ別の使用量とは異なります。Dataにインストール済みアプリすべてのアップロード量とダウンロード量が表示されるとは限りません。アプリ別の分類が表示される場合は、まずラベルの意味を確認してください。サーバー、接続、ドメインの記録だけが表示される場合は、現在の項目を使って分析します。存在しないメニューを探す必要はありません。
| 確認する視点 | 確認に適した内容 | 主な制約 |
|---|---|---|
| サーバー | どのプロキシ出口の数値が増えたか | 通信を開始したアプリを完全には特定できない |
| アプリの分類 | 識別可能な通信元のうち、どれが通信したか | 識別できる範囲はシステムや画面の機能によって異なる |
| ドメインまたは宛先アドレス | リクエストがどのネットワーク上の宛先にアクセスしたか | 同じ宛先を複数のアプリが使う場合がある |
| リクエストとルールの記録 | 個々のリクエストにどのポリシーが適用されたか | テスト時刻と宛先を対応させる必要がある |
ブラウザーでページを1つ開いただけでも、メインドメイン、画像、フォント、APIの各ドメインにアクセスする場合があります。また、ほかのアプリが同じコンテンツ配信先を利用することもあります。ドメインが表示されても、それを使っているアプリが1つだけとは限りません。バックグラウンド同期、システム通知、キャッシュも観測結果に影響します。操作していない間に通信が発生することもあれば、キャッシュ済みのページを再度開いても通信量がわずかな場合があります。
結論：通信元と出口を分けて確認する
まず、1つのアプリから新しいリクエストを1回だけ送信し、確認範囲を絞ります。次に宛先アドレスと適用されたポリシーで出口を確認してください。サーバーの合計値が増えたというだけで、その増加分すべてを直前に開いたアプリの通信とみなさないでください。
Global Routingとルールの記録で振り分けを確認する
ルールを検証する前に、HomeでGlobal Routingを確認します。Proxy、Direct、Config、Sceneはそれぞれ異なる状態です。Proxyはプロキシ経由のルーティング、Directは直接接続、Configは現在の設定に基づく処理、Sceneは選択中のシーンの設定を確認する必要があります。Config内のルールが適用されるか検証するには、接続が有効かどうかだけでなく、現在のモードがConfigであることを確認してください。
以下は構文を確認するための最小限の例で、既存の設定を置き換えるためのものではありません。example.comは例示用のドメインです。192.0.2.0/24は文書用の予約アドレス範囲で、実際の接続テストには使えません。変更前に元の設定を保存し、設定内のポリシー名が実際に存在することを確認してください。
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIXは指定したドメインとそのサブドメインに一致します。メインページとリソースのドメインが異なる場合、それぞれ別のルールに一致することがあります。IP-CIDRは宛先IPアドレスの範囲で照合します。例のno-resolveは、このIPルールのためにドメイン名を追加で解決しないことを示します。接続全体でDNSが不要という意味ではありません。GEOIPは宛先IPアドレスを地理情報データベースの分類に基づいて照合します。Webサイトの表示言語やドメインの末尾で判定するものではありません。FINALは、それ以前のルールに一致しなかったリクエストを処理します。問題を調べる際は、適用されるはずのルールだけでなく、リクエストが最終的にどのルールに一致したかも確認してください。
ルールは通常、設定された順に評価されます。先に一致したルールによって、後続のルールがそのリクエストを処理しない場合があります。Dataに通信量の増加しか表示されない場合、どのルールが適用されたかを特定することはできません。アプリに表示されるリクエストやログの記録で、テスト対象、時刻、一致したルール、実際のポリシーを照合してください。具体的な確認場所は現在の画面に従い、統計の行をルール適用ログとみなさないでください。
再確認できるテスト：合計ではなく差分を比較する
同じネットワーク、同じサーバー選択、同じ設定を維持し、前面で動作するアプリを1つ使って短時間のテストを行います。ほかのダウンロードや同期は一時停止しますが、システムのバックグラウンド通信は発生する可能性があります。通信を完全に止めることが目的ではありません。対象のリクエストと時間帯を明確にし、記録と照合できる状態にします。
- 条件を記録：Wi-Fiかモバイル通信か、Global Routing、現在のConfig、サーバーの項目、接続状態を記録します。ここではサブスクリプションを更新しません。
- 開始値を記録：Dataで対象項目のアップロード量とダウンロード量を記録します。画面にリセット機能があれば使用できますが、前後の差を比較する方法にリセットは必須ではありません。
- 新しいリクエストを送信：ドメインを確認できるページを開き、時刻を記録して約60秒観察します。この時間はテスト用であり、性能基準ではありません。
- 終了値を記録：同じ統計項目を読み取り、計測範囲が同じか、途中で再接続やネットワークの切り替えが発生していないか確認します。
- 照合：対象リクエストの記録にある出口と、Dataの増加量を照合します。設定を1つ変更したら、新しいリクエストを送信して再度テストします。
たとえば、あるサーバーのダウンロード量が開始時に120 MB、終了時に128 MBなら、差は8 MBです。これは計算例であり、実測値でもページ本文のサイズでもありません。この間にバックグラウンド通信があれば、差分にはその通信量も含まれます。統計が整数MB単位でしか表示されない場合、小さなリクエストでは数値に変化が見えないこともあります。
結論：変更する条件は1つだけ
まず設定を固定して出口を確認し、次にルールを1つだけ変更して、新しいリクエストを確立してから再テストします。同じテストでサブスクリプションの更新、ネットワークの切り替え、サーバーの変更を同時に行うと、数値が変わった原因を特定できません。
サブスクリプションの更新でサーバー項目が変わる場合があり、Configの変更で通信の振り分け結果が変わる場合もあります。どちらもテストとは分けて実施してください。利用者がすでに契約しているサブスクリプションを更新する場合は、更新を完了して選択中の項目を再確認してから、新しいテストの開始値を記録します。更新前後に同じ名前で表示されるサーバーの統計値を、連続したデータとみなさないでください。
よくある疑問と確認の手順
Webページは開けるのに、サーバーの通信量がほとんど増えないのはなぜ？
まずHomeでGlobal Routingを確認し、対象のリクエストにDIRECTまたは別のポリシーが適用されていないか調べます。次に新しいリクエストを送信してキャッシュの影響を除外し、別の同名項目ではなく対象サーバーの数値を見ていることを確認してください。Webページが開けたというだけで、選択中のサーバーを経由したとは判断できません。
アプリを開いていないのに、アップロード量やダウンロード量が変わるのはなぜ？
ネットワーク条件を変えずに短いアイドル時間の数値を記録し、前面でアプリを1つ操作した場合と比較します。バックグラウンド同期、システム通信、既存の接続でも通信が続く場合があります。宛先アドレスと時刻を使って対象を絞り込み、合計値の変化だけから、特定のアプリがファイルをアップロード中だと推測しないでください。
アプリ別統計の項目が見つからないのはなぜ？
まず、現在のDataにどの分類項目が表示されているか確認してください。サーバー一覧をアプリ一覧と混同しないようにします。アプリの帰属情報がない場合は、前面で1つのアプリだけを使い、時間帯を固定して、対象リクエストの記録と照らし合わせます。システム独自の通信量統計は、その計測方法に従って確認し、トンネルの累計値から直接差し引かないでください。
Dataの数値が増えているのに、ページでエラーが出るのはなぜ？
データが送受信されたことから分かるのは、通信が発生したということだけです。まず失敗したリクエストのエラー情報と適用されたポリシーを確認し、次に宛先への到達性、DNS、接続パラメーターを調べます。ハンドシェイク、エラー応答、再試行でも通信量は増えるため、通信が発生していることだけでは、リクエストの成功や速度が正常であることの十分な証拠にはなりません。
確認が終わったら、再検証に必要な情報だけを残します。テスト時刻、ネットワークの種類、ルーティングモード、宛先ドメイン、出口ポリシー、数値の差分を記録してください。診断情報を共有する前に、サブスクリプションのURL、アクセストークン、パスワード、秘密鍵を隠します。統計のスクリーンショットやログは、問題に関係する部分だけを残し、設定全体を公開する必要はありません。