Shadowrocket Data Usage: How to Read Traffic by Server and App

What upload, download, and speed mean in Data

Open the Data statistics page in Shadowrocket. The location and grouping may vary with the current interface, so follow the labels shown on your device. First distinguish cumulative data from live transfer speed: cumulative figures show how much has been transferred, while speed shows how fast data is moving right now. When page loading stops, the speed may drop close to zero, but the cumulative total does not automatically reset.

If the same item shows Upload at 2 MiB and Download at 10 MiB, the combined total is 12 MiB. This is an example of how to read the figures, not a performance test. The page may round individual values before displaying them, so adding the displayed decimals may differ slightly from the total’s last digit.

By server: see which proxy exit handled the traffic

Server grouping shows which proxy exit traffic passed through, not the name of the app that initiated a request. This assumes you already have your own provider and connection details. An increase for a server entry means traffic within the selected scope was attributed to that exit; it does not mean all network activity on the device passed through it.

Check Home → Global Routing. Proxy, Direct, Config, and Scene are different routing modes, not four types of traffic counters. With Config, connections are matched against rules in the active configuration; the server selected on Home does not necessarily handle every connection. A Scene’s behavior depends on its settings, so its name alone does not reveal the exit used.

• Proxy: Connections covered by the proxy policy use proxy routing; check connection records to confirm the actual exit.
• Direct: Connections use the direct policy, so do not expect proxy server counters to increase with all browsing activity.
• Config: Check the active configuration in Config. DOMAIN-SUFFIX, GEOIP, IP-CIDR, and FINAL can route different connections to different policies.
• Scene: Check the settings used by the scene before interpreting server counters. Don’t change an existing scene just to make the figures line up.

For example, if rules send some domains to DIRECT and other connections through a proxy exit, the traffic should not all be attributed to one proxy server entry. If the page lists direct traffic separately, read it separately from proxy entries. If a server is renamed or its details are imported again, don’t assume the new entry represents the same statistics object as the old one based on its displayed name alone.

By app: read the categories, not as system-wide usage

The app view groups connections the client can identify into relevant categories. Distinguish between categorizing traffic based on connection information and a per-app byte count supplied directly by the system. On iPhone and iPad, don’t assume every connection inside the tunnel has a reliable source app identity. You also can’t infer app-level data that the current page doesn’t show from a server name.

Domains, destination addresses, and connection characteristics can help identify what is being accessed, but they don’t always point to one specific app. Several apps may use the same content delivery domain, and one app may contact separate domains for sign-in, images, video, and analytics. If a record is unknown or uncategorized, leave it that way rather than assigning it to the last app you opened.

When counters reset: identify the starting point first

Don’t assume that disconnecting the VPN, quitting the app, or crossing midnight resets all Data records. Current connection counts, cumulative statistics, and connection logs may have different lifecycles. A live speed reading dropping to zero after disconnecting does not mean historical totals were deleted; clearing logs does not necessarily reset all traffic counters.

1. In Data, identify the group you’re viewing. Note the time, item name, Upload and Download values, and whether the page specifies a statistics period.
2. If the current page offers Reset or a clear-statistics option, read the confirmation prompt and check its scope first. Reset only the statistics you’re testing; clearing records is not a routine requirement.
3. After the action, return to the same group and check whether the target counter has reset. If other groups are unchanged, that does not mean the action failed.
4. If there’s no clear reset option, calculate usage for a period by subtracting the starting reading from the ending reading. There’s no need to delete your configuration or reinstall the app.
5. Keep the start and end times for every comparison. Track the system’s cellular period, the client’s cumulative period, and your provider’s billing period separately.

For example, if Download starts at 120 MiB and ends at 132 MiB, the download increase for that interval is 12 MiB. If the counter resets in between, the ending value will be lower than the starting value and the difference is no longer meaningful; establish a new baseline. Check the current page’s information and your own observations to determine whether a type of cumulative record is saved persistently. Don’t assume one restart’s behavior applies to every statistic.

Why Data differs from carrier and provider records

These three figures answer different questions. Data records traffic observed by the client; your carrier records usage for billing on its network; a provider you already use may count service usage according to its own rules. A comparison is meaningful only when the network type, time range, upload/download direction, and units match.

• Wi-Fi and cellular cover different traffic: Client readings generated over Wi-Fi should not be expected to appear on a cellular bill. Switching networks during a test means the same Data increase may span both types of access.
• The tunnel and the measurement point differ: Proxy protocol encapsulation, encrypted records, handshakes, and keepalives add bytes. Whether a counter measures traffic before or after encapsulation affects how its total compares with network-side measurements.
• Retransmissions and failed requests can still use data: A page failing to load doesn’t mean no data was transferred. Whether that traffic appears in a particular reading depends on where it is measured.
• Not all traffic goes through the same server: DIRECT, other policy exits, and system activity outside the statistics scope all affect how the entries relate to one another.
• Providers may use their own billing rules: Check the terms for any service you already use, including how it combines uploads and downloads, applies multipliers, handles reporting delays, and defines billing periods. Don’t use one client reading as a substitute.
• Units and precision vary: Decimal GB and binary GiB convert differently. Rounding can also affect results in small-traffic tests.

On iPhone and iPad, system cellular usage is usually available under Settings → Cellular. The exact label varies by system language and region. The current period shown there may not automatically match your billing month. Before manually resetting system statistics, save the existing figures; a system reset does not also reset Shadowrocket’s Data.

Check traffic with one controlled action

You don’t need to run repeated speed tests while troubleshooting. A speed test itself generates substantial traffic and can obscure requests from the app you’re monitoring. The steps below verify categorization and changes in usage; they don’t measure protocol performance and don’t require changing server ports or existing connection settings.

1. Keep the network consistent: Choose either Wi-Fi or cellular and stay on it throughout the test. Pause other large transfers and note the time.
2. Keep the routing consistent: Note the current Home → Global Routing mode and active configuration. If you’re using Config, confirm which policy the test destination is expected to match.
3. Record a baseline: Note the upload and download readings for the overview, target server, and any available app groups. You don’t need to reset them first.
4. Perform one action: Load one specific page in the app you’re monitoring, then wait for its requests to finish. Avoid repeated refreshes or playing media at the same time.
5. Compare the readings: Return to the same group, wait for the interface to refresh, and subtract the starting value from the ending value. Check the connection record to confirm the destination and exit.
6. Check automatic reconnection: If you need to pause monitoring, check Settings → On Demand. On-demand connection rules may reconnect automatically, so one manual disconnect may not be enough.

If the increase is smaller the second time you open a page, consider local caching before concluding that traffic wasn’t counted. If the total still rises slightly with no foreground activity, check for background refreshes, notification connections, name resolution, or keepalives. A small, steady increase alone doesn’t indicate an unusual download.

Common questions about readings and what to check

To analyze Data, first align the time range and units, then verify the actual policy, and finally review app categorization and billing methods. If you need to share troubleshooting details, include the start and end readings and describe what happened. Before sharing connection records, hide server addresses, authentication details, and the full link to any subscription you already use.