Shadowrocket’s Data tab shows traffic recorded by the client, not your provider’s billing totals. If you already have a server configured, start by distinguishing upload, download, and total figures. Then check traffic by server and app, and compare before-and-after readings from a controlled visit to see whether routing behaved as expected. This guide also covers when statistics begin and how to troubleshoot differences caused by background traffic or other factors.
1. Traffic volume is not connection speed
Traffic figures in the Data tab show how much data has been transferred. Upload is data sent from your device; download is data received by your device. Opening a webpage generates upload traffic when requests are sent, and download traffic as text, images, and video arrive. Upload is usually more noticeable when you send a photo. Even when you’re mainly downloading, upload traffic is not necessarily zero: connection setup, requests, and acknowledgments still send data.
Check the unit before interpreting the number. KB, MB, and GB measure data volume; units expressed per second indicate speed. A large cumulative download figure only means that more data was received during the period being observed. It does not show your current speed and is not a substitute for the connection check in Connectivity Test.
Traffic statistics do not confirm that a request succeeded. A failed request may have sent data before stopping because of a DNS, handshake, or remote response issue. Conversely, a page loaded from the local cache may display normally while generating very little new traffic. Consider Data readings alongside the actual result of the visit.
2. What traffic by server and by app can tell you
The server view shows how much traffic a particular server entry carried during the period being measured. The app view shows traffic attributed to identifiable apps. These are different ways to look at the same kind of network activity, not two separate amounts that can be added together as plan usage.
| View | What it can show | What it cannot prove on its own |
|---|---|---|
| By server | Cumulative traffic or the increase during this observation period for a server entry | That every app used this server |
| By app | Traffic distribution and growth for identifiable apps | That every request from the app used the same policy |
| Upload and download | The difference between the amounts sent and received | Real-time bandwidth, latency, or remaining plan allowance |
App attribution also depends on information provided by the system and the statistics currently available. If a record cannot be clearly attributed, do not assume it belongs to an unknown app or a suspicious process. An app may contact multiple domains, and its traffic may include both direct and proxied requests, so traffic attributed to an app does not map one-to-one to traffic on a particular server.
Takeaway: Compare both views over the same time window
First note the current readings for the server and app you want to check, then use just one app. Compare the increases over the same period. Do not compare a server’s historical total with a small amount of newly recorded app activity.
3. When do statistics start, and why aren’t they billing totals?
Traffic must pass through Shadowrocket and be recorded for it to appear in the statistics. The date you installed the app, made your purchase, or imported a subscription does not necessarily mark the start of the current Data figures. Nor should every field be interpreted as covering only the time since you opened the screen: current connection data and retained cumulative records need to be considered separately.
To determine when a statistic starts, check whether the current screen clearly shows a time range, connection duration, or reset status. If no time period is shown, do not describe the figure as “today’s usage” or “this month’s usage.” Check how the field actually changes after disconnecting; do not assume that reconnecting clears all historical data.
- Measuring a visit: Note the readings and time before you start, then record them again afterward. Use the difference as your observation window.
- After switching servers: Save readings from before and after the switch. Do not treat the old server’s cumulative total as traffic used on the current server during this session.
- After clearing or resetting data: Record when you did it and use that moment as the new comparison point. Do not subtract the pre-reset cumulative total.
- Checking your remaining allowance: Check the usage page provided by your service provider. The provider determines the billing period and how traffic is counted.
The client and your service provider may count traffic at different points. Protocol overhead, statistics refresh intervals, traffic multipliers, and billing cycles can all affect the figures, so the two totals may not match exactly. Cellular data usage shown by the device is another measure and may include system activity that Shadowrocket did not handle. Do not treat figures from these three places as interchangeable without checking what each one covers.
4. A five-step method for a repeatable traffic check
You do not need to change server settings or reimport a subscription for this check. Start with your existing configuration. If you do not have a subscription, obtain one from your service provider. Choose one clear action, such as opening an uncached page in Safari. Avoid playing video, updating apps, or syncing large numbers of photos at the same time.
-
Check the connection
Go to Home and confirm the selected server in the SERVER list. Turn on the connection switch at the top, then run Connectivity Test. Treat the test as one indication of connectivity and also open the page you want to check.
-
Check the routing mode
Go to Home → Global Routing and note whether the current mode is Config, Proxy, Direct, or Scene. If Config is selected, check the active configuration in Config. Do not switch modes in the middle of the test.
-
Record a baseline
Open Data and note the current upload and download figures and the time for the server and app you want to check. Pause other foreground downloads for now, and remember that background syncing may continue.
-
Visit the page
Return to Safari, load a page once, and note the start and end times. Do not switch between Wi-Fi and cellular or change servers during the test; doing so makes changes in traffic attribution harder to interpret.
-
Compare the change
Return to Data, wait for the figures to refresh, and record the same fields again. Subtract the earlier readings from the later ones, then consider the result alongside whether the visit succeeded, the current routing mode, and the request records.
The figures below are examples of how to calculate differences, not measured results or performance guarantees. Keep units consistent. If the interface rounds the figures, a small amount of traffic may not show a clear change. In that case, observe for longer rather than assuming the statistics are not working.
| Field | Before | After | Change during this period |
|---|---|---|---|
| Server download | 100 MB | 120 MB | 20 MB |
| Server upload | 10 MB | 11 MB | 1 MB |
5. Use Global Routing to check whether traffic is routed as expected
Data provides clues from the results; Global Routing and the active configuration determine how traffic is handled. Before interpreting an increase in server traffic, check the current routing mode. In particular, do not observe traffic in Proxy mode and conclude that a rule in Config was matched.
Config
RecommendedThe active configuration’s rules determine which policy is used. When checking routing, verify the target request, the matching rule, and the final policy. Do not assume that requests with no matching rule will automatically go direct.
Best for: Verifying that the current configuration routes traffic as expected
Proxy
Routes traffic covered by this mode through the proxy path, making it useful as a connectivity comparison. It does not prove that a DOMAIN-SUFFIX or IP-CIDR rule in Config is working.
Best for: Temporarily distinguishing server issues from rule issues
Direct
Uses a direct connection. If server proxy traffic does not increase, that may be expected in this mode. A zero server reading alone does not indicate a connection failure.
Best for: Comparing how a target behaves over a direct connection
If you use Scene, first check its settings and activation conditions. Do not assume Scene is simply a fourth mode equivalent to Proxy or Direct. Keep the same scene active before and after the test for a meaningful comparison.
Rule order also matters in Config. DOMAIN-SUFFIX matches domain suffixes, GEOIP matches against an IP geolocation database, IP-CIDR matches IP address ranges, and FINAL handles requests that did not match earlier rules. The matched rule’s specified policy determines where a request goes, not the app’s name.
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXYThis example is only to explain the rule syntax: example.com and its subdomains match DIRECT, while FINAL sends all other requests to PROXY. Before testing, make sure the configuration supports the referenced policies; do not overwrite your existing configuration just to observe traffic. A full webpage may also request resources from other domains, so some traffic may use a proxy even when the main domain connects directly.
Takeaway: An increase in traffic only shows that data passed through
To confirm whether a target matched the expected rule, check the target, matched rule, and final policy in the request records for the same visit. Use the increase in Data as supporting evidence; do not rely on the total traffic for the whole page instead of checking requests individually.
6. Troubleshoot unusual readings by symptom
Note what you observe before changing settings. Record the time, network type, Global Routing mode, and target. This is usually more useful for identifying the cause than repeatedly reconnecting. Change just one condition at a time, then make another visit and record Data again so you can separate the effects of each change.
The page loads, but why hasn’t server traffic increased?
First check whether Home → Global Routing is set to Direct, then see whether the target matches DIRECT in Config. Retry with uncached content and wait for Data to refresh. A cached page, rounded figures, or checking the wrong server entry may make the increase hard to see.
Why does traffic keep increasing when I’m not doing anything?
Pause cloud sync, media playback, and app updates, then check the increase in the app view. Next, go to Settings → On Demand and check whether it is enabled and under what conditions; this can reveal whether a connection is being triggered automatically. Return to Home to check the actual connection status rather than relying on whether you previously turned the switch off.
Why don’t an app’s figures match the server figures?
Use the same start and end times for both readings, and stop activity in other apps. The app may generate both direct and proxied requests, while the server may carry traffic from other apps. App attribution and rounding can also affect the comparison, so the two cumulative totals are not expected to match exactly.
What if my provider reports more usage than Data?
First align the billing periods, then check your provider’s information about traffic multipliers and refresh delays, as well as usage on other devices on the same account. Data is for observing traffic in the client; use your provider’s bill to check your remaining allowance. Do not include subscription links or credentials when sharing troubleshooting materials.
Wrap up each check by recording four things: the current connection, the current routing mode, the before-and-after traffic difference, and the final policy for the target request. If both Connectivity Test and the actual visit fail, start by checking network or server connectivity. If the visit works but takes an unexpected route, go back to Config and check rule order. Data is one part of the troubleshooting process, not a diagnosis on its own.