Data is useful for tracking traffic changes, but it cannot by itself confirm that a specific rule matched or verify a provider’s usage totals. For iPhone and iPad users who have already configured a connection, this guide explains how to compare upload and download usage, understand how traffic is grouped, and run a test using before-and-after readings over the same time window. Check Global Routing, Config, and connection logs to understand where traffic went.
1. Distinguish Total Data from Transfer Speed
Read Shadowrocket’s Data usage along with its units. Upload is data sent from your device; download is data received by your device. Browsing a webpage also uses upload because the browser sends requests and connection details. A larger download total does not mean upload should be zero, and an increase in upload does not necessarily mean a file is being uploaded.
KB, MB, and GB measure data volume; KB/s and MB/s include a time component and measure transfer speed. The first group describes the amount of data transferred over a period, while the second describes the rate of transfer. A large total only shows that a lot of data has been transferred; it does not mean the current speed is high. The total will not decrease when a page finishes loading or the speed drops.
The 60-second window is a suggested testing method, not a fixed refresh interval for Data. Whether stats are retained, when they refresh, and which groups are shown depends on the current page on your device. Before comparing readings, note the time, units, and grouping so you do not compare yesterday’s total with a single webpage request today.
2. By Server vs. By App: Don’t Add the Two Views Together
When viewing usage by server, check whether a server entry’s upload or download total changed during the observation window. This tells you whether traffic associated with that server entry changed; it does not tell you that one foreground app used all the traffic. Multiple apps may use the same server, and routing changes may send different connections from the same app through different outbound routes.
When viewing usage by app, focus on traffic the page can identify and assign to an app entry. App identification on Apple platforms has limitations, so this view is not a complete audit of every app on the system. System services, background tasks, or connections that cannot be clearly attributed may not appear under the expected app name. Trust the categories actually shown rather than guessing from their names.
| View | Useful for answering | Cannot establish on its own |
|---|---|---|
| By server | Which server entries gained traffic during this test | That all increases came from one foreground app |
| By app | Whether identifiable source entries transferred more data | That every request from the app matched the same rule |
| Upload and download | How much sending and receiving increased, respectively | That the figures exactly match the provider’s billed usage |
How to compare: check changes within each view; don’t add the totals
First compare readings before and after the test within the same view, then check whether the other view changed in the same direction. Server and app are different ways of grouping traffic. Adding the figures from both views may count the same traffic twice and will not give you a more accurate total.
3. Measurement Differences and Resets: Keep a Record, Then Set a Baseline
Data, system network usage, and provider statements may differ in their time ranges, coverage, protocol overhead, and unit conversions. Even when you observe the same download, the figures in all three places are not expected to match exactly. In particular, do not treat the download total shown by the app as your subscription’s remaining allowance. Check your provider’s information for your allowance and billing period.
Resetting stats shortens the observation window; it is not a required connection fix. Disconnecting and reconnecting, quitting the app, or updating a subscription should not be taken as proof that usage stats will reset. If the current Data page offers a reset control, first confirm whether it applies to one entry or the entire view, and save any readings you need. Don’t infer the control’s scope from its icon or position.
- Record first: Save the server name, upload and download readings, the time, and the current Global Routing mode.
- Choose a baseline: If you need to keep the history, use the current readings as your starting values without resetting. For a fresh observation window, use the reset control provided on the page.
- Check the result: After resetting, check the target view again. Background connections may cause the readings to increase soon after; they do not need to stay at zero.
- Keep conditions consistent: Use the same network, test resource, and duration for the next round. After switching between Wi-Fi and cellular, record a new round.
4. Check Traffic Routing: Start with Global Routing
Data shows traffic changes; rules determine how requests are routed. Neither replaces the other. Check Global Routing on Home: only when using Config should you check the active configuration’s rules to understand a match. If Proxy or Direct is selected, do not explain the result using a domain rule in Config. If you use Scene, first check the active scene and its settings before testing.
The examples below illustrate rule syntax; they are not a replacement configuration to paste over your existing setup. PROXY must refer to a policy that is actually available in your current configuration. example.com is a demonstration domain and cannot be used to verify how your own traffic is routed.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX: Matches a domain suffix. Images, videos, and API requests on the same page may come from other domains.IP-CIDR: Matches a destination IP range. In this example,no-resolvemeans not to perform a DNS lookup specifically for this IP rule.GEOIP: Matches based on the IP address’s geographic location. The language shown by a website does not tell you whether this rule matched.FINAL: Acts as a fallback when no preceding rule matches. Also check whether an earlier rule matched first.
In Config, confirm which configuration is active and check the rule order before making a new connection. Long-lived connections established before a rule change may continue using their original outbound route, so refreshing Data alone does not guarantee that a request will be evaluated again. Stop the previous test, make a new request, and check the available connection logs for the destination domain or IP, matching rule, and outbound policy.
5. Run a 60-Second Comparison Test: Use Changes to Narrow It Down
Pause other high-traffic tasks before testing, and choose a resource you are authorized to access and can request repeatedly. Keep the connection and server selection on Home unchanged, note the starting Data readings, then observe for 60 seconds. Do not update a subscription, change protocols, or edit rules at the same time; otherwise, it will be difficult to tell which change affected the readings.
| Example readings | Before test | After test | Change during test |
|---|---|---|---|
| Server download | 120 MB | 132 MB | 12 MB |
| Server upload | 8 MB | 9 MB | 1 MB |
The figures in the table are for demonstrating the calculation, not results from a performance test. A 12 MB increase in downloads over 60 seconds works out to an average of about 0.2 MB/s for that window. This includes any waiting time and is not the peak speed during the download. If the page rounds its readings, the difference is approximate too and is not suitable for comparing very small requests.
Next: Match Usage Changes to Specific Connections
If the target server’s total increases and the test resource loads successfully, that only supports the conclusion that the server transferred data during the test. To confirm that a specific domain was routed correctly, check the request’s rule and outbound policy as well. If the readings do not change, first rule out caching and existing connections before investigating rules or configuration.
To compare Direct and proxy routes, run separate test rounds, setting a fresh baseline each time and changing only one condition. A page served from browser cache may generate almost no new downloads. You can use a test resource you control that lets you confirm a fresh request, but avoid unnecessary large transfers that consume your plan.
6. Common Questions About Data Readings and What to Check
Why does Data keep increasing when I’m not browsing?
First pause known tasks such as syncing and media playback, then observe a fixed window. Background requests, connection keepalives, and system services can all use data. If you configured On Demand in Settings, also check whether its conditions are triggering a connection. A small increase alone is not enough to conclude that unusual data transfer is occurring.
A webpage loads, but the selected server’s usage hasn’t changed. Did routing fail?
First check Global Routing and the selected server on Home, then check the active configuration in Config. The resource may have loaded from cache, used Direct, or gone through a server selected by another policy. Make a new request and check the connection logs; that is more useful than repeatedly toggling settings.
What if the app I’m using isn’t listed under usage by app?
An app not appearing by name does not mean it is not using the network. First check overall changes and server usage for the same window, then confirm the connection using its destination and time. Keep attribution uncertain when an entry cannot be identified reliably; do not force all unidentified traffic into a particular app’s category.
Do I need to reset usage stats after updating a subscription?
First check whether the server entries, policy references, or current selection have changed. Subscription updates and usage resets are separate operations. Keep the old readings and set a new starting value to continue testing. If an entry has been replaced, do not assume that readings before and after the update form one continuous record just because the displayed name is the same.
When troubleshooting is complete, restore the routing settings you need and keep a record of these six details: time, network, configuration, server, starting and ending readings, and test destination. Use Data to spot changes, connection logs to understand where traffic went, and provider information to check your allowance. Keeping these roles clear makes problems easier to reproduce than repeatedly resetting stats. For basic steps, see the Global Routing guide. For DNS issues, see DNS troubleshooting.