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

First, distinguish direction, speed, and total data

Upload and download are measured from the device’s perspective: data sent from the device is upload, and data received by it is download. Opening a webpage involves both sending requests and receiving content. Video playback is usually download-heavy, but still involves requests, acknowledgments, and status updates. So seeing both figures rise at the same time does not necessarily indicate an unexpected connection.

A value followed by /s is a transfer rate; a byte value without a time unit is an amount of data. The live figure beside the connection status in Home is not directly comparable to the cumulative figure in Data. Always interpret a total in the context of its displayed scope: the current connection, an individual entry, and retained history may each start counting at a different time.

Note the difference between uppercase B and lowercase b: one byte contains 8 bits. Network bandwidth is often shown in Mbps, while app transfer rates are often shown in MB/s; the numbers are not interchangeable. Counters may also use different unit conversions or display precision. Keep the units shown in the interface when comparing values, and avoid rounding before subtracting.

By server vs. by app: two different views

The server view shows which server entry traffic is assigned to, not which app made the request. When multiple apps use the same proxy outbound, their traffic contributes to the same server counter. The server selected in Home also does not necessarily carry every request. The actual route depends on Global Routing, the current Config, and the policy specified by the rules.

The app view focuses on the attributed source of a request. A single app’s connections may follow different policies, so its traffic cannot be equated with the traffic on one particular server. Whether a source can be identified also depends on information provided by the system and the connection type. If an app is not listed separately, that does not mean it had no network activity. If the current Data page has no app view, use the available server statistics and connection records instead; don’t treat a domain entry as an app name.

Check the route before interpreting which counter is rising

Data shows traffic totals; it does not prove which rule matched. With Global Routing set to Proxy, ordinary requests use proxy mode; with Direct, they use direct mode; with Config, the current configuration determines the route. Scene involves scene settings, so don’t infer the final policy from the mode name alone—check the configuration active for that scene.

In Config mode, rules are generally matched in order. DOMAIN-SUFFIX matches a domain suffix, IP-CIDR matches an address range, GEOIP uses an IP geolocation database, and FINAL handles requests that did not match earlier rules. If a request matches DIRECT, the expected proxy server’s counter may not increase; that alone does not prove the connection failed.

1. In Home, note the current Global Routing mode and confirm the server entry in use.
2. If you use Config, check the configuration that is actually active in Config—not just a file with a similar name.
3. Check the rules for the target domain, including earlier rules and FINAL. Don’t rewrite all your rules just to make a counter increase.
4. Use the destination and actual policy in the connection records to determine the route, then check the corresponding entry in Data for a change.

When do totals reset? Check the counter’s scope first

Don’t assume that “disconnect” means “clear all Data records.” Ending a connection ends that session, but whether its cumulative history is retained depends on the counter’s scope and the current interface behavior. Reopening the app, switching servers, or updating an existing subscription should not be treated as a reliable way to reset counters.

Keep current-session figures separate from historical totals. If the interface clearly shows that a figure applies to the current connection, interpret it from that connection’s start. If it shows a cumulative total for an entry, don’t assume that the value comes from the current connection. If no start time is shown, the safest approach is to compare before and after, rather than guess that counting began today, this month, or when the app was purchased.

• Manual reset: If the current Data page offers a clear or reset action, read the confirmation prompt first, check its scope, and then proceed. Treat only the counters explicitly cleared as having a new starting point.
• Removing an entry: Deleting and recreating a server may change how statistics are attributed. It is not a suitable routine reset method and makes continuous comparisons harder.
• Reconnect: Check whether the session and cumulative figures change independently. Don’t assume that resetting one also cleared the other.
• Periodic tracking: To track usage by week or month, record the date and starting and ending values yourself. Don’t assume Data resets automatically to match a billing period.

For example, if the download total is 120 MB at the start of an observation and 138 MB at the end, the increase is 18 MB—provided it is the same entry and scope, with no reset in between. These figures are illustrative, not measured results. If you switch entries or clear a record during the observation, the two values no longer form a valid comparison.

Data and iOS cellular usage don’t match? Check these four factors

On iPhone or iPad, go to Cellular in Settings to view the cellular usage figures provided by iOS. This measures something different from Shadowrocket Data: iOS tracks cellular network usage, while Data tracks traffic handled by the app and assigned to the relevant scope. The system’s Current Period is not necessarily your carrier’s billing period; check the statistics reset time shown at the bottom of the page.

Proxy protocols exchange data to establish connections and keep sessions active, so the actual amount transferred over the network may not match the size shown for a webpage or attachment. Connection reuse, retries, and caching can also affect the change caused by a single action. A small difference between Data and system usage alone does not prove duplicate billing or a statistics error. First compare the same network, time window, and scope.

Use a 60-second observation to identify ongoing traffic

These steps are for observing counter changes, not testing speed, and do not require changing an existing service provider or subscription. Save your current settings before you start and pause obvious background downloads. Don’t switch networks, servers, or modes during an observation. If Settings → On Demand is configured, note whether it may trigger an automatic connection so you don’t mistake an automatic reconnection for the result of a manual test.

1. Record the setup: Note the time, Wi-Fi or cellular network, Global Routing, current Config, and server entry.
2. Record starting values: Open Data and note the upload and download totals for the target entry. If an app view is available, note the target app’s starting values too.
3. Observe while idle: Avoid using the device for 60 seconds, then record the ending values. This shows the baseline from background connections and session maintenance.
4. Test one action: Run another 60-second observation. Open one known webpage or load one uncached item, then record the same counters.
5. Compare the results: Calculate the change for each observation and use connection records to check whether the new traffic came from the expected destination. Keep all other conditions the same if you repeat the test.

If a page loads from cache, the increase may be small. If a video or webpage preloads content, the counter may continue rising briefly after you stop viewing it. If upload keeps increasing, first check for attachments being sent, photo syncing, and other background tasks. Don’t judge an anomaly by the direction of the change alone. A transfer counter shows that data was exchanged; it does not prove the requested content loaded successfully.