Data shows traffic recorded by the client, not your provider’s usage bill. First distinguish cumulative usage from current speed, then check outbound traffic by server and its source by app. Finally, compare changes over the same time window with connection logs to verify routing. This guide is for users who have imported a subscription and want to understand differences in the stats or check routing results. App attribution and reset options vary by platform; refer to the current interface.
Understand usage, speed, and provider-reported traffic
Start with the units shown in Shadowrocket’s Data view. B, KB, MB, and GB indicate cumulative data usage; B/s, KB/s, and MB/s indicate data transferred per unit of time. When a download stops, the speed drops while the cumulative total remains—that’s normal. A total of 20 MB is not a current download speed.
Upload is data sent from your device; Download is data received. Loading a web page also generates Upload because requests, sign-in state, and acknowledgments are sent. Uploading a file also involves Download, as the server sends responses back. If the interface shows Total, first check whether it means the combined traffic for that row or a summary for the current view, so you don’t add a parent total and its items twice.
Your provider measures traffic at the other end, potentially using a different billing period, multiplier, and method for counting protocol overhead. Client stats, system cellular usage, and your provider’s dashboard are not measured on the same scale. Any remaining data shown in a subscription response is also separate from the local stats in Data. Get your subscription link from your provider, and check your plan balance and billing period with them as well.
For example, a file labeled 100 MB won’t necessarily increase the totals in Data, system settings, and your provider’s dashboard by exactly 100 MB. Protocol overhead, caching, retries, and measurement boundaries all affect the result; MB and MiB may also be calculated differently. Align the time window and units before comparing differences.
By server: see which outbound connection carried the traffic
In the server view, focus on how much a server’s stats changed during the test, not its historical total or ranking. The server selected on Home may not immediately match the one used by existing connections. Reused connections or an unfinished download may continue using the original server. After switching servers, make a new request before checking the stats.
| What to check | What it means | How to verify |
|---|---|---|
| Server name | The server entry associated with traffic recorded by the client | Compare it with the entry on Home; don’t identify it by a similar name alone |
| Upload / Download | Cumulative usage or speed for that entry and direction, depending on the unit | Record the starting and ending values; don’t compare historical totals |
| Direct | If shown in this view, traffic recorded as direct | Check Global Routing and connection logs to identify its source |
| The entry hasn’t changed | The test traffic may have used another outbound route, or no new connection may have been made | Check caching, connection reuse, stats refresh, and the policy actually matched |
The server list is not a complete record of all network activity. Whether direct traffic appears separately and whether historical entries remain depends on the current interface and stats scope. Even if the selected server’s total hasn’t changed, that alone doesn’t mean the device is offline. The request may have used Direct, a server selected by another policy, or a route outside the current stats scope.
- On Home, confirm the current server and note its starting Upload and Download values in Data.
- Pause other high-traffic tasks, then make a new network request from one app.
- Wait for the request to finish, return to Data, and record the ending values in the same units.
- Subtract the starting values from the ending values to get the increase, then compare it with connection logs for the same period.
By app: identify the source without treating missing entries as zero
The app view answers “where did the traffic come from?”; the server view answers “which outbound route did it use?” These views may describe the same traffic, so don’t add them together to calculate total device usage. One app can access multiple domains that match Direct and proxy policies, while one server can carry connections from multiple apps.
How clearly traffic can be attributed to an app depends on platform permissions and how traffic is captured. On iPhone and iPad in particular, don’t assume the system provides the client with complete per-app identity information. If the current interface has no app view, or some connections appear without a clear app attribution, continue troubleshooting with server changes and connection logs. There’s no need to look for a setting that isn’t available in the current interface.
- A browser doesn’t connect to just one domain: A page may request images, fonts, media, and APIs at the same time. An app’s total usage can’t prove that every request matched the same rule.
- Background activity doesn’t always stop: Sync, notification-related connections, and background transfers may still use data. Minimize other activity during a test.
- A zero in the interface doesn’t mean there was no access: Cached responses, delayed refreshes, and limited app attribution can all make traffic increases invisible during a test.
- App and server totals don’t have to match row by row: They may use different attribution boundaries. Compare the same time window first, then check individual connections.
When do stats reset? Check the counter’s scope first
There’s no single answer to “Does disconnecting reset the stats?” The current session duration or speed is not the same as the cumulative total saved in Data. Disconnecting ends the current session, but doesn’t necessarily clear all historical stats. Returning to Home, changing Global Routing, or updating a subscription shouldn’t be treated as a general reset either.
| Action or time | How to interpret it | What to record |
|---|---|---|
| Turn off the connection | The current session ends; cumulative saved stats may remain | Record the same entry before and after disconnecting |
| Quit and reopen the app | Reloading the interface doesn’t necessarily clear saved stats | Compare values and stats scope before and after reopening |
| Midnight or your plan’s billing date | Unless a reporting period is clearly specified, don’t assume local stats reset automatically | Check whether the interface specifies a date range |
| Clear stats | Follow the confirmation prompt in the current interface; it may apply only to a specific scope | Save any values you need first, then verify what was cleared |
If you need a fresh count, first check whether Data on your platform offers an option to clear or reset stats. Read the confirmation prompt before proceeding. Don’t rely on button locations from another platform, and don’t delete servers, subscriptions, or app data just to reset the count. If there’s no clear reset option, subtract the starting value from the ending value to get a reliable test window.
Bottom line: compare changes instead of relying on a reset
For each test, record the start and end times, server name, and both sets of readings. This separates the traffic for that test even when historical stats remain. Resetting only changes your baseline; it doesn’t reset your provider’s bill or plan balance.
Check Config rules with Data: control variables before checking matches
To test rules in a configuration file, select Config under Home → Global Routing, then confirm the active file in Config. Proxy and Direct can be used for a temporary comparison, but their results don’t prove that a rule in the configuration file matched. If you use Scene, confirm which routing settings the active scene applies so you don’t mistake a scene change for a rule failure.
Record the state before testing
- Global Routing
- Config
- Configuration file
- Confirm the selected file in Config
- Server
- Note the current selection on Home
- Automatic connection
- Settings → On Demand
Check whether On Demand conditions could change the connection state, and keep the network environment consistent throughout the test.
Rule syntax example
- DOMAIN-SUFFIX
- example.com,PROXY
- IP-CIDR
- 192.0.2.0/24,DIRECT,no-resolve
- GEOIP
- CN,DIRECT
- FINAL
- PROXY
The example domains and network ranges explain the syntax; they aren’t targets for real connectivity tests. Put FINAL last.
Here’s an example set of rules to illustrate their order. DOMAIN-SUFFIX matches a domain and its subdomains; IP-CIDR matches a destination IP range, and no-resolve means the rule won’t trigger a DNS lookup just to check for a match. GEOIP classifies traffic based on the destination IP’s geographic database entry. FINAL handles requests that haven’t matched any earlier rule. Rules are evaluated from top to bottom, so an earlier rule can change the final result.
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYFor a real test, use a target you know is reachable and covered by your existing rules. There’s no need to paste the examples into your everyday configuration. Record the starting values in Data, then open the target and check the connection log for its domain or IP, matched rule, and final policy. HTTPS commonly uses destination port 443, but the port alone doesn’t prove that a request used a proxy. Check the actual match and outbound route.
- Set a baseline: Confirm the connection is on, pause background downloads, and record the server and app stats.
- Make a new request: Don’t just refresh a page served entirely from cache. If you switch test resources, keep the target policy consistent.
- Check the connection: Find the matching time and target first, then check the rule and outbound route—not just the server total.
- Compare the change: Wait for the stats to refresh, then calculate the difference. If the result doesn’t match expectations, check rule order and existing connection reuse first.
- Restore your settings: If you temporarily switched to Proxy or Direct for comparison, restore your original Config settings when the test is done.
Bottom line: traffic growth is supporting evidence; connection matches pinpoint the cause
If a server’s Download total rises from 12 MB to 17 MB, that only shows the entry gained about 5 MB. It doesn’t prove that a particular domain matched DOMAIN-SUFFIX. Identify the relevant connection first, then use the change in Data to confirm that traffic continued to flow through it.
Common stats questions and how to troubleshoot them
Why is Upload increasing when I’m not downloading anything?
Pause cloud sync, file uploads, and other background tasks. Record the change over one minute, then check connections from that period. Web requests, keepalive traffic, and acknowledgments also generate Upload. An increase alone doesn’t mean a file is being uploaded.
Why is the old server still showing traffic after I switch servers?
Let existing downloads finish, then start a new connection and check its outbound route. Old connections may still be transferring data, or a policy may select a different server. Don’t delete the old entry to test this; identify the relevant request by its connection time and destination.
What if the app I just opened doesn’t appear in the app stats?
First check whether your platform provides app attribution, then make sure you aren’t just seeing cached data. Make a new request and compare server stats with connection logs. Leave unattributed traffic marked as unknown rather than guessing which app it belongs to.
Data and my provider’s dashboard show very different totals. Should I change my rules?
First align the start time, end time, and units, then ask your provider to confirm the billing period and measurement method. Rules determine how requests are routed; they don’t make the two sets of stats match. Check Config only if connection logs show that the outbound route differs from what you expected.
Why won’t a web page load even though Data shows traffic?
The increase may come from another app, a handshake before a failure, or repeated requests. First check whether the connection to the target succeeded, then check DNS, the matched rule, and outbound status. For more detailed troubleshooting, follow the steps one by one; total traffic growth is not proof of connectivity.
To keep troubleshooting notes, record the device platform, Global Routing mode, configuration file, server name, test target, and time window. Before sharing logs, remove subscription links, authentication details, and personal browsing information. For help checking connections or importing a subscription, see Troubleshooting and Getting Started.