Shadowrocket Data Usage Guide: Server vs. App Statistics

What Data tracks: traffic attribution vs. evidence of rule matches

Shadowrocket’s Data tab shows traffic recorded by the client. It is not a complete record of all network activity on your device: connections that do not pass through the client cannot be assessed from these figures. Whether app names are recognized, and how much detail is shown, depends on the platform and current implementation. If an app does not appear by name, that does not mean it has not used the network.

The server view answers which server carried the traffic; the app view shows which identifiable app the traffic is attributed to. These are two ways to group the same network activity, not separate usage totals to add together. Nor does every row in the app list mean the traffic went through a proxy. Check routing and connection records to determine the actual path.

This flow illustrates a troubleshooting sequence; it does not mean every counter in the interface measures traffic at the same point. Statistics may show that a server’s traffic increased during a test, but they cannot, by themselves, prove that a specific domain matched a particular rule. To verify that, check request or connection records for the same time period and compare the destination, policy, and actual outbound route.

Upload, download, and total usage: check the units, then compare changes

Upload is data sent from your device; download is data received by it. Loading a web page usually involves both an uploaded request and a downloaded response. Streaming content can also generate uploads, such as acknowledgments and progress reports. So upload traffic while you are only watching content is not, by itself, evidence of a problem. Rate describes activity around a sampling moment; total usage is the amount transferred over a reporting period.

For example, suppose the same statistic shows 120 MB downloaded before a test and 138 MB afterward. The displayed increase for that window is 18 MB. This is a calculation example, not a measured result or a guarantee of a web page’s file size. If the interface rounds units, small amounts of traffic may not show up right away. Wait for a refresh or extend the observation window rather than concluding that the connection did not use that route.

Server vs. app views: keep the test subject consistent

For a server-side check, note which server is selected in Home, then check whether the active configuration and its policies in Config could select another server. Changing the selection in Home does not necessarily move every existing connection immediately; policy choices and connection reuse can affect the actual outbound route. If a server is renamed, a subscription is updated, or an entry is replaced, do not combine old and new totals into one continuous record just because their names look similar.

For an app-side check, try to have just one target app make a new network request. Multiple browser tabs, background sync, and in-app preloading can all add noise. If Data on your platform cannot show the app attribution you need, cross-check the time window against connection records for the target domain instead. Do not assign an unidentified entry to an app without evidence.

When counters reset: use an explicit reset or a recorded baseline

Do not assume Data resets at midnight, whenever you reconnect, or every time you restart the app. Nor should you assume its counters follow your provider’s billing cycle. The retention period may differ between statistics. If the interface does not say when a counter was reset, treat that time as unknown—do not call the current total “today’s usage.”

1. Record a baseline first. Note the time, platform, active configuration, server name, and the totals you plan to track. If you need to keep a history, a written record is enough; you do not need to delete anything to run a test.
2. Check what the reset affects. If the current Data view offers a clear or reset action, read its instructions or confirmation prompt first. Check whether it applies to the current entry or all statistics. Button names vary by interface.
3. Reset only if needed. If you choose to reset, do so before a controlled test and wait for the interface to refresh. Confirm that the intended reading changed. Do not reset midway through a test, or the before-and-after figures will no longer share a baseline.
4. Use a difference if there is no clear reset option. You do not need to delete a server or configuration, or reinstall the app, to start from zero. For troubleshooting, subtracting the starting value from the ending value is usually more useful.

Check routing: verify a request in Config and connection records

To check a rule, first confirm that Home → Global Routing is set to Config. Proxy, Direct, and Config have different routing behavior, so tests under the first two modes do not prove that custom rules are working. If you use Scene, also check which configuration and policies the active scene uses. Then confirm in Config which configuration is in use—not just that a file has been imported.

DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

This diagram shows the order of operations only: rules are evaluated from top to bottom, the matched rule’s policy is applied, and FINAL is the fallback. PROXY must refer to a valid proxy policy in the configuration. example.com is a sample domain, not a test route. IP-CIDR and GEOIP match IP-based conditions; they are not domain categories. Check the destination’s resolution and connection records to confirm the actual result.

1. Stop any large file transfers and media playback in progress, then note the starting values of the relevant Data statistics. Pausing other activity can reduce noise, but do not assume background traffic has stopped completely.
2. Make a new request in the target app and note the time and full destination domain. Choose an action you know will access the network; simply opening a cached page may not generate a request.
3. Wait for the request to finish, return to Data, and record the ending value for the same statistic. If you use a fixed window, observe for 60 seconds each time rather than comparing a few seconds in one test with several minutes in another.
4. Check request or connection records from the same period and verify the destination domain, matching policy, and actual outbound route. If the rule should use DIRECT, the proxy server’s total does not have to increase for that request.
5. For a comparison test, change just one setting at a time and start a new connection. If needed, end the old connection first to avoid confusion from connection reuse.

Common Data questions: billing differences, no increase, and changes after disconnecting

Finally, Data shows recorded transfer activity; it cannot explain on its own why a web page is slow. Check server connectivity, DNS, destination response time, and network quality separately. If a connection fails, see Troubleshooting. Change one setting at a time, then repeat the same test over the same window so the readings are comparable.