この記事は、Shadowrocketに自分が利用しているサブスクリプションを読み込み、通信の経路を確認したい方を対象としています。まずサーバー別とアプリ別の2つの見方を整理し、テスト前後のアップロード・ダウンロード量の差から通信を確認します。最後にGlobal Routingと接続記録を照合して、ルールの適用結果を確かめます。Dataはクライアント上の通信状況を確認する画面であり、サービス提供元のプラン残量ではありません。累計値だけで、リクエストに適用されたルールを特定することもできません。
Dataの統計範囲：方向・データ量・速度を区別する
ShadowrocketのDataでは、クライアントが記録した通信状況を確認できます。アップロードはデバイスから外部へ送信されるデータ、ダウンロードは外部からデバイスへ受信するデータです。Webページを開くと、通常は両方の数値が増えます。リクエストや応答、アプリの同期にもアップロードが発生するため、ファイルを送信するときだけ通信量が増えるわけではありません。
まず単位を確認しましょう。KB、MB、GBはデータ量を表し、/sが付く単位は通信速度を表します。ダウンロード累計が120 MBでも、現在もダウンロード中とは限りません。また、ある時点で0 B/sと表示されても、それ以前に通信がなかったという意味ではありません。以下の数値は計算方法を示す例であり、性能テストの結果やプランの課金条件を示すものではありません。
Dataは、デバイス全体のあらゆる通信を網羅する記録ではありません。統計対象は、クライアントの処理経路を通った接続、システムから取得できる情報、画面上の分類範囲によって異なります。その経路を通らない通信がDataに表示されるとは限りません。また、システムのモバイルデータ通信量と数値が一致するとも限りません。
サーバー別に確認する：どの出口で通信量が増えたかを見る
サーバー別表示では、累計値が最大の行を探すだけでなく、各サーバーのアップロード・ダウンロード量がどう変化したかを確認します。以前の利用記録が残っているサーバーもあれば、現在選択中のサーバーで新しいリクエストが発生していない場合もあります。名前が似た項目があるときは、Homeに戻って該当する項目を確かめ、同じ出口だと取り違えないようにしてください。
- Homeで現在選択しているサーバーを確認し、Global RoutingがProxy、Direct、Config、Sceneのどれになっているか記録します。
- Dataを開き、対象サーバーを見つけて、テスト前のアップロード・ダウンロード量と時刻を記録します。
- ブラウザーで自分がアクセスできるテストページを開くなど、内容が明確な操作を1回だけ行い、読み込みが終わるまで待ちます。
- Dataに戻り、表示が更新されるのを待って同じ行の数値を記録し、前後の差を比べます。
たとえば、ある項目のダウンロード量が120 MBから128 MBに増えた場合、表示精度で見ると観察中の増加量は約8 MBです。その時間帯にその項目でダウンロードがあったことは分かりますが、8 MBすべてが直前に開いたページによるものとは限りません。バックグラウンド同期やほかのアプリのリクエスト、ページ内の複数のリソースも同じ出口を使うことがあります。
アプリ別に確認する：アプリの識別と接続先は別の情報
アプリ別表示では「どの識別可能な通信元が通信したか」、サーバー別表示では「どの出口が通信を処理したか」を確認します。同じ通信を異なる角度から見たものなので、両方の合計を足し合わせないでください。1つのアプリが複数のドメインにリクエストし、PROXYとDIRECTの両方を使うことがあります。また、1台のサーバーが複数のアプリのリクエストを処理する場合もあります。
アプリの識別は、システムから得られる情報に左右されます。アプリ名が表示されない記録や、まとめて分類された記録、接続情報だけが表示される記録は、ドメイン名だけを根拠に特定のアプリからの通信だと判断しないでください。共有サービスやWebページ内のリソース、システムのバックグラウンド処理が、似たアドレスにアクセスすることもあります。Dataは、システムによるアプリごとの通信監査とは異なります。
- 通信元を確認：ほかのアプリでの操作をいったん止め、対象アプリの行の数値を記録してから、そのアプリだけで1回更新します。
- 通信先を確認：サーバー別の増加量と該当する接続記録を同時に確認します。アプリの行が増えただけでは、プロキシ経由か直接接続かは分かりません。
- 空欄への対処：現在のデバイスでアプリの情報が表示されない場合、名前を推測して補わず、リクエスト時刻、接続先ドメイン、実際に適用されたルールを照合してください。
- 誤判定を防ぐ：アプリをバックグラウンドに移しても、通信がすぐに止まるとは限りません。テスト終了後もしばらく通信量が増えることがあります。
Global Routingとルール記録でPROXY・DIRECTを照合する
統計を読み取る前に、Home → Global Routingを確認します。Proxyはプロキシ経由のルーティング、Directは直接接続、Configは現在の設定にあるルールによる振り分け、Sceneは選択中のシーンで定義された条件と設定に従って動作します。Sceneを「すべてプロキシ経由」にする固定モードと考えないでください。ルールファイルを検証するにはConfigを使い、確認対象の設定がConfigで実際に有効になっていることを確かめます。
Global Routingの確認
- モード
- Home → Global Routing
- Proxy
- プロキシ経由のルーティング。個々のルールによる振り分けの検証には使いません
- Direct
- 直接接続。プロキシサーバーの通信量増加を成功の基準にしません
- Config
- 現在の設定にあるルールの適用結果を使用
- Scene
- 現在のシーンの条件とルーティング設定を確認
テスト中はモードを変えず、切り替え前後の数値を混同しないようにします。
ルールの最小構成例
- DOMAIN-SUFFIX
- example.com,PROXY
- IP-CIDR
- 192.168.0.0/16,DIRECT,no-resolve
- GEOIP
- CN,DIRECT
- FINAL
- PROXY
構文の説明用の例です。example.comはサンプルドメインです。現在使用中の設定全体をこの内容で上書きしないでください。
設定の[Rule]セクションでは、各ルールを完全な1行で記述します。通常、ルールは上から順に照合され、最初に一致したルールのポリシーが適用されます。FINALは最後に置いて、ほかのルールに一致しない通信の受け皿にします。no-resolveは、このIPルールのためにドメイン名の名前解決を新たに行わないことを示します。GEOIPが判定するのは接続先IPの所属地域であり、ページ上の文言やドメインの末尾から地域を推測するものではありません。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY1回のアクセスを確認するには、接続記録から該当する時刻と接続先を探し、実際に一致したルール、ポリシー、送信先を確認します。PROXYの送信先がポリシーグループの場合は、グループ内で実際に使用されたサーバーも確認してください。DNSやリダイレクト、ページ内のサブリソースによって接続が追加されることがあるため、ページを1回読み込んでも適用されるポリシーが1つとは限りません。
結論：ルールの適用結果と通信量の増加をあわせて確認
特定のリクエストがPROXYを経由したかを判断するには、まずそのリクエストに一致したルールと実際の送信先を特定し、同じ時間帯のサーバー別通信量の増加で裏付けます。DIRECTの場合もリクエストの記録を確認してください。プロキシサーバーの通信量が増えていないことだけでは判断できません。
統計の範囲とリセットのタイミング：基準値を記録してからテストする
リセットは新しい観察期間を始めるための操作で、ルーティングの問題を直すものではありません。接続の切断と再接続、サーバーの切り替え、Subscribeの更新、Configの再選択をしても、累計値が必ずゼロになるわけではありません。画面によって累計値の対象範囲が異なることがあるため、操作前にどの範囲を確認しているか把握してください。
- 基準値を記録：時刻、サーバー名、ルーティングモード、アップロード・ダウンロード量を記録します。トラブルシューティングでは、関連する接続記録も保存してください。
- 対象範囲を確認：Dataのリセット操作を使う場合は、画面の説明を読み、対象が現在の項目だけか統計全体かを確認します。対象範囲が明記されていない場合は、操作前後の差を計算する方法を優先してください。
- バックグラウンド通信を減らす：制御できる大容量ファイルの転送やメディア再生を一時停止します。ただし、すべてのバックグラウンド処理がすぐに停止するとは限りません。
- 同じ時間枠で測定：テストを1回終えてから数値を記録します。テスト中にサブスクリプションの更新、サーバーの切り替え、設定の変更をしないでください。
- 結果を保存：観察した増加量とルールの記録をまとめて保存し、次のリセットテストを始めるかどうかはその後に判断します。
クライアントの数値をリセットしても、サービス提供元が記録した利用量やプランの期間はリセットされません。双方がアップロードとダウンロードを集計していても、プロトコルのオーバーヘッド、再送、集計位置、表示単位、更新時刻の違いによって差が出る場合があります。比較するときは、まず期間と単位をそろえてからサービス提供元の課金方法を確認してください。期間の異なる合計値を比べて異常と判断しないようにしましょう。
よくある数値の疑問：現象を特定し、1項目ずつ再テストする
Webページは開くのにサーバーの通信量がほとんど増えません。Shadowrocketを経由していないのでしょうか？
必ずしもそうとは限りません。まずHome → Global Routingを確認し、そのリクエストにDIRECTが適用されているかを見ます。キャッシュされたページでは主なリソースが再ダウンロードされず、小さな通信は表示精度に反映されない場合があります。新しいリクエストが発生することが明確な操作を行い、接続記録でクライアントの処理経路を通ったか確認してください。
ファイルをアップロードしていないのに、アップロード量が増え続けるのはなぜですか？
Webページへのリクエストや接続確認、アプリの同期でもアップロードが発生します。メディア再生や制御可能な転送を止め、1分間の観察時間を決めて記録してから、新しい接続の接続先と時刻を確認してください。増加が特定のリクエストと結び付いて初めて、通常のバックグラウンド通信か、アプリの動作を見直す必要があるかを判断できます。
新しいサーバーを選んだのに、古いサーバーの通信量が少し増えるのはなぜですか？
切り替え前に確立された接続がまだ終了していない場合や、設定内のポリシーグループが別の出口を選んでいる場合があります。接続の確立時刻、一致したポリシー、実際に使われたサーバーを確認してください。切り分けテストが必要な場合は、業務への影響を許容できることを確認したうえで現在のテスト接続を終了し、リクエストを再度実行します。Homeで選択中のサーバーだけを見て、既存の接続もすべて切り替わったと判断しないでください。
接続を切断したのに、しばらくして新しい通信が発生した場合はどうすればよいですか？
まずシステムのVPN状態とSettings → On Demandを確認し、自動接続の条件によって接続が再確立されていないか調べます。数値の更新が遅れているだけの場合もあります。トラブルシューティングのために一時的にOn Demandを停止する場合は、元の設定を記録してから行い、テスト終了後に設定を戻してください。自動再接続を、統計が止まっていない現象と取り違えないようにします。
アプリ別の合計とサーバー別の合計が異なる場合、どちらを基準にすればよいですか？
2つの表示では分類範囲が異なる場合があり、識別できない通信元やDIRECTの通信も比較に影響します。まず同じ時間帯の記録かを確認し、リクエストごとに照合してください。サービスの残高を確認する目的なら、利用中サービスのアカウント記録を確認します。Dataの合計値をそのまま請求額とみなすことはできません。
あとから確認できる通信量テストの記録を残す
有効な確認では、次の3点を特定できる必要があります。どのアプリがどのリクエストを行ったか、ルールがどのポリシーを適用したか、対応する出口で妥当な通信量の増加があったか、です。以下は手動記録の形式です。数値は計算例であり、一定の通信量を示すものではありません。テストドメインは、自分が正当にアクセスでき、観察しやすい接続先に置き換えてください。記録にサブスクリプションの認証情報を含めないでください。
| 記録項目 | テスト前 | テスト後または確認結果 |
|---|---|---|
| Global Routing | Config | Configのままにする |
| 対象サーバーのアップロード量 | 12 MB | 13 MB、約1 MB増加 |
| 対象サーバーのダウンロード量 | 120 MB | 128 MB、約8 MB増加 |
| リクエストの結果 | 接続先と開始時刻を記録 | 一致したルール、ポリシー、実際の出口を確認 |
現象を再現できない場合は、まず同じ操作を繰り返してください。プロトコル、サーバー、ルールを同時に変更しないでください。トラブルシューティング用の情報を共有する前に、サブスクリプションURL、トークン、パスワード、キー、個人のアクセス記録を必ず隠してください。Dataは判断材料を示す画面です。通信元、ルール、出口、通信量の増加を同じ時間帯で照合することで、あとから検証できる結論を導けます。