Data helps you monitor traffic handled by Shadowrocket. It is not the same as your device’s cellular usage or your provider’s billing records. This guide is for users who already have a subscription and server details from their provider and want to check usage. First, distinguish cumulative data from real-time speed. Then review usage by server and app, and compare changes over the same time window.
Data usage, live speeds, and plan usage are different
Shadowrocket’s local stats, system network stats, and your provider’s records each measure traffic at a different point. Interpret Data readings in the context of the selected category and recording period. They are not the total usage for your iPhone or iPad, and they cannot tell you exactly how much your plan has been charged. The units, category labels, and recording start point matter more than any single number.
Upload usually means data sent from your device; download means data received by your device. For example, video streaming is mostly download traffic, but it also involves requests, acknowledgments, and other uploads. A unit ending in /s indicates a rate; a byte value without a time denominator is cumulative data. A high speed at one moment does not mean that speed was sustained throughout the reporting period.
For example, 8 Mbps theoretically equals 1 MB/s, before accounting for protocol overhead. MB and MiB are also different units: 1 MB is 1,000,000 bytes, while 1 MiB is 1,048,576 bytes. Before comparing two screens, confirm how each defines its units. Similar abbreviations do not guarantee the same conversion method.
View by server: identify which outbound connection carried the traffic
The per-server view shows proxy outbound usage: which server entry handled requests, where traffic was concentrated, and whether new requests moved after a switch. A server entry does not correspond one-to-one with a provider plan. One plan can include multiple servers, and multiple devices may use the same plan. So the cumulative total for one entry on this device cannot represent the whole account’s usage.
- In Home, check the currently selected server and note its name. If multiple entries share a name, also check the address and port so you do not mistake one entry for another.
- Check Global Routing. With Config, routing follows the rules in your configuration. With Proxy or Direct, ordinary requests use different outbound routes, so the readings are not directly comparable.
- Open Data and review the server stats shown. Note the upload and download readings for the relevant entries and the recording period. Use the categories available on your current screen.
- After a brief test, read the same entry again. Use the change to confirm whether it carried the test traffic; do not rely only on the size of its historical total.
Switching servers does not immediately move every existing connection to a new one. Video streams, persistent connections, or background transfers may continue on the original connection until it closes or is recreated. A small increase in the old entry after switching does not, by itself, mean the selection failed. For a useful comparison, end the test, start a new request, and check the next change in usage.
How to check: compare changes for the same entry
To check whether the current server is being used, keep Global Routing and the test task unchanged, and record readings before and after. Do not compare one entry’s long-term total with another entry’s short-term reading.
View by app: useful for attribution, not a complete system inventory
The per-app view answers “which source can these observed connections be attributed to?”—not “how much carrier data did every app on this device use?” App identification on Apple platforms has permission and system capability limits. If Data offers app categories, use the categories and attribution results actually shown. An app missing from the list does not prove it is offline, and not every connection can necessarily be matched to an app name.
A single foreground action can trigger requests to multiple services, while background syncing may happen at the same time. Conversely, multiple apps may access the same domain or share a system service. A domain, server address, or connection time alone is usually not enough to identify the originating app. Treat the per-app view as a troubleshooting clue, then verify it by testing one action at a time.
Per-server checklist
- Where to look
- Check the selection in Home; view stats in Data
- What it covers
- A specific server entry and its proxy outbound traffic
- Before you start
- Note the current Global Routing mode
- How to compare
- Changes for the same entry over the same period
Useful for checking outbound usage, not as a substitute for account billing records.
Per-app checklist
- Where to look
- App categories actually shown in Data
- What it covers
- Connections that can be observed and attributed
- Before you start
- Confirm which categories are available and what they include
- How to compare
- Pause other tasks and use only the app you want to check
Useful for finding traffic sources, not as a substitute for system cellular usage stats.
To investigate cellular plan usage, also check the usage for each app in the system’s Settings > Cellular or Mobile Data screen. The menu name varies by system language and region. Check the reporting periods for system cellular stats and Shadowrocket’s local stats separately. Data sent over Wi-Fi cannot explain a cellular bill.
Run a traffic comparison you can repeat
You do not need to clear all historical records for a useful comparison. Keep the starting readings and subtract them from the ending readings to calculate the change, preserving information that may help with later troubleshooting. The figures below are a calculation example, not measured results or a performance claim.
- Keep conditions consistent: Use one network, keep the same server and Global Routing mode, and pause cloud syncing, app updates, and transfers from other devices on the same account.
- Record the starting point: Note the time, upload and download readings in Data, and the usage shown in your provider’s account dashboard, including when it was last refreshed. Any remaining-usage figure in subscription details may also reflect an earlier refresh.
- Run one task: Open just one target app and perform an action with a clear start and finish. Web caching and video preloading affect actual transfers, so do not treat a page’s stated file size as a network reading.
- Record the end point: When the task is finished, wait for connections to become idle, then read the same fields again. If your provider’s dashboard updates with a delay, wait for it to refresh before recording the result. Do not repeat the task just to fill in the numbers.
- Calculate the difference: Calculate the upload and download changes separately, note the test period, and compare them with your provider’s published usage rules.
| Reading | Before | After | Change |
|---|---|---|---|
| Cumulative upload | 20 MB | 22 MB | 2 MB |
| Cumulative download | 100 MB | 150 MB | 50 MB |
| Upload and download total | 120 MB | 172 MB | 52 MB |
This example shows only that the selected local stats increased by 52 MB. It does not prove that your provider should deduct 52 MB, or that the target app’s actual content was exactly 50 MB. Check separately whether upload and download are both counted, whether a multiplier applies, and whether other devices were using the account.
Why readings differ: measurement points and routing decisions vary
This flow explains why the numbers may not line up: an app requests content, Shadowrocket handles connections within its scope, rules determine how they are routed, and the provider measures traffic at its own network boundary. Each measurement point may cover a different range of bytes and reporting period. Direct traffic does not automatically count toward a proxy server plan just because it was handled locally.
With Config selected in Global Routing, rules in Config are checked from top to bottom, and the first match determines the policy. The following is a syntax example, not a recommendation to replace your existing configuration. Use the policy names defined in your own configuration.
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXYIn this example, requests matching example.com and its subdomains use DIRECT. Next, GEOIP,CN,DIRECT handles matching IP addresses, and requests with no earlier match go to the final rule, FINAL,PROXY. A single browsing session can therefore create connections that take different routes. Ignoring the individual policies and comparing only the local total is a common source of discrepancies.
- Protocol overhead: TLS, proxy protocol headers, and connection maintenance add data. App content size, bytes sent through a tunnel, and bytes counted at the server’s network interface are not the same thing.
- Retransmissions and reconnects: Unstable connections can add traffic, but different measurement points account for retransmissions differently. There is no single percentage you can apply to correct every reading.
- Account aggregation: Your provider’s dashboard may combine multiple servers, devices, and upload and download traffic for one account, while the local view shows only some records from this device.
- Usage rules: Billing multipliers, billing periods, time zones, and dashboard refresh delays can all cause discrepancies. Ask your provider for the specific rules that apply to your account.
- Automatic connections: Conditions in Settings → On Demand may start the tunnel automatically, and background syncing can transfer data at the same time. A locked screen does not mean all network activity has stopped.
Align these four factors before comparing usage
Match the device scope, start and end times, upload/download coverage, and units before comparing. If the discrepancy persists, keep readings from the same test window and ask your provider how usage is measured.
FAQs: reset readings, background usage, and unexpected uploads
Data readings dropped or reset. Does that mean my plan renewed?
Not necessarily. First check whether the selected server, category, or recording period changed, then check whether you reset the stats, reinstalled the app, or restored data. A change in local records does not mean your provider’s billing changed. Check your remaining plan usage in the provider’s account dashboard.
Why is usage increasing when I haven’t opened a webpage?
Pause photo syncing, file transfers, and media playback first, then check whether the increase slows down. Next, review automatic connection conditions in Settings → On Demand. Background notifications, syncing, and existing connections can continue to transfer data. No foreground activity does not, by itself, mean the stats are wrong.
What should I check if uploads are higher than expected?
Record the upload change over five minutes and check for cloud backups, video calls, or file uploads. If Data provides app attribution, pause the relevant entries one at a time to verify. Do not assume a server problem just because cumulative uploads exceed downloads.
Will resetting Data make my provider recalculate usage?
Resetting local stats affects only local records; it does not change how your provider measures usage. If the current screen offers a reset option, save your readings and review the confirmation prompt first. For a comparison, use the difference between readings instead of resetting. Do not assume that reconnecting, refreshing a subscription, or switching servers will clear account usage.
When investigating traffic, save your readings before changing settings. Your provider can usually investigate with the start and end times, units, server entry, and upload/download changes. Before sharing records, hide credentials in subscription URLs, account identifiers, and private information in access logs. For more on routing or setting up your first connection, continue with the guides on this site.