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

1. Find Data and distinguish totals from transfer rates

From the Shadowrocket main screen, open Data and review the available statistics. In the server view, check the sent, received, and total figures for the relevant server. In the app view, first confirm that the list actually attributes traffic to apps; don’t mistake a destination domain or connection name for an app name. Available categories can vary by device and interface. The app-view guidance here applies only when that category is shown.

Cumulative traffic answers “How much data was transferred during this statistics window?” and is typically shown in KB, MB, or GB. A figure with a per-second unit answers “How fast is data moving right now?” These figures aren’t directly comparable. If the app is in the background, the transfer rate may drop to zero, but that doesn’t mean the accumulated byte count has disappeared.

• Sent: Usually data sent from the device, including requests, uploads, and related communication. It isn’t limited to the size of uploaded files.
• Received: Usually data delivered to the device, including web resources, media segments, and responses.
• Total: Check how the interface defines this field. Don’t add it to sent and received again, or you’ll double-count the traffic.

2. Traffic by server: Find which connection actually transferred data

The server view helps answer, “Did this test use the expected server?” It isn’t a provider’s remaining-quota page or a summary of all network usage on the device. A server name is just a way to identify an entry; entries with the same name, or entries recreated after a subscription update, may not share the same statistics identity. Before comparing them, check the server address, port, and group.

Selecting a server in Home doesn’t mean every connection must use it. When Global Routing is set to Config, connections follow the rules and policies in the active configuration. A rule may select another policy or use DIRECT. If the selected server’s counter doesn’t increase, first check the destination connection’s actual outbound route rather than assuming the statistics are broken.

3. Traffic by app: App attribution isn’t a device-wide usage bill

The app view shows traffic distribution for apps that can be identified, but it shouldn’t be treated as a system-wide list of app usage. Attribution depends on information exposed by the client and the system. Some connections may not have a clear app name and may appear as unidentified. An app missing from the list doesn’t mean it never connected to the network.

A single app may access multiple domains for sign-in, images, video, and analytics, with some connections routed through a proxy and others through DIRECT. Conversely, multiple apps may use the same domain. A domain list, app list, and server list show different dimensions; one domain record alone can’t establish the outbound route for an entire app.

1. Close foreground apps that aren’t part of the test and pause obvious background downloads. Note the test start time.
2. Open just one target app and perform one specific action, such as refreshing a page. Avoid playing media or syncing photos at the same time.
3. Return to Data and check whether the app or an unidentified entry shows new traffic, then compare the change against the server reading.
4. If there’s no app view, use the destination address, time, and outbound route in the connection log instead. Don’t treat a domain name as proof of app attribution.

4. Statistics periods and resets: Save a baseline before resetting

Don’t assume Data resets automatically each month, or that the start of a VPN session is the starting point for every statistic. If the interface labels a session, date range, or cumulative period, use that as the reference. If no start point is shown, establish a traceable baseline now. Disconnecting, quitting the app, or updating a subscription shouldn’t be treated as reliable ways to reset statistics.

To reset, look for Reset or the corresponding statistics-reset action on the Data page. If it’s in a page action menu, open the menu and check the confirmation prompt to see what will be affected. If the interface doesn’t offer a reset, there’s no need to delete a configuration or reinstall the app; subtract the readings before and after the test instead. Don’t confuse deleting a server, clearing connection logs, and resetting statistics.

1. Save the old readings: Note the date, time, category, server identifier, and sent and received values. If you need a history, save a local record first.
2. Pause test traffic: Stop downloads or playback. Check the triggers under Settings → On Demand to avoid unexpected automatic connections during the test, then restore the original settings afterward.
3. Confirm the reset scope: Read the confirmation prompt and distinguish the current category, a single entry, and all statistics. Proceed only as the prompt describes; don’t assume every category will reset together.
4. Check immediately: Return to the same category, verify the result, and record the new starting point. If a small amount appears right away, check for background traffic instead of resetting repeatedly.

Test window: start reading to end reading
Sent increase = ending sent value - starting sent value
Received increase = ending received value - starting received value
Total increase = sent increase + received increase

Use consistent units before calculating. This is an example for illustration only, not a measured result: if received traffic starts at 120 MB and ends at 128 MB, the increase during the window is 8 MB. If statistics were reset during that period, or an entry was replaced and its reading decreased, don’t subtract these values directly. Record a new baseline instead.

5. Verify routing with Data: Match rule logs to traffic changes

An increase in traffic proves only that data was transferred; it doesn’t by itself show which rule matched. A complete check requires confirming Global Routing, the active configuration, the rule matched by the destination connection, and its actual outbound route. Proxy, Direct, Config, and Scene in Global Routing aren’t statistics categories. Select Config to verify configuration rules; when using Scene, first check its actual settings.

1. Go to Home → Global Routing and select Config. Then open Config and confirm which configuration file is active; don’t assume a file you edited is enabled.
2. Record the current Data reading for the expected server, then end any existing test connection from the target app. Rule changes are usually easiest to verify with a new connection.
3. Send a request to a known destination, then check the connection log for its destination domain or IP, matched rule, and actual outbound route. Use the location of the connection log in the current interface.
4. Return to Data and compare the change for the same server. Also check whether another server’s traffic increased and rule out background traffic.
5. For a controlled comparison, change one variable at a time—for example, change only the destination rule. Don’t change the server, network, and DNS settings together.

The rule structure below is illustrative and uses a reserved example domain; it doesn’t represent a usable service. Refer to PROXY by name only if the active configuration has an available policy named PROXY. If the existing configuration uses another policy name, keep it. Don’t replace the entire configuration just to test statistics.

DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

In this example, connections to example.com and its subdomains are sent to PROXY, while FINAL sends the rest to DIRECT. In an actual configuration, rules such as DOMAIN-SUFFIX, GEOIP, and IP-CIDR are evaluated in order; an earlier match may prevent later rules from being reached. Check the specific connection log rather than simply confirming that a keyword appears in the file.

6. Data and provider usage differ: Align the basis before comparing

A provider’s usage statement may use a different billing period, upload and download calculation, multiplier, or refresh interval. Data reflects the local traffic the client can track. Protocol overhead, where traffic is measured, and unit conversions can also cause differences. Even when both show GB, their byte conversions and billing definitions may not match.

• Align the time period: Compare the same start and end times. Don’t subtract the provider’s usage for the current month from Data’s historical cumulative total.
• Align the devices: A provider account may combine usage from other devices; Data on this device doesn’t show that traffic.
• Align the traffic direction: Check whether the provider counts received traffic, sent traffic, or both, and whether it specifies a billing multiplier.
• Align the refresh time: After local readings increase, the provider’s page may not have updated yet. Wait for its stated refresh interval before comparing.

Plan limits or expiration details shown beside a subscription entry are provider-supplied data, if returned by your existing provider; they aren’t local Data counters. Updating a subscription doesn’t guarantee that Data will reset, and resetting Data won’t change usage already recorded by the provider. Keep and assess these two types of information separately.

7. FAQ: Zero readings, background traffic, and what a reset changes