Use Data to observe traffic changes, not as sole proof that a specific rule matched. This guide assumes you already have a provider and subscription. First, distinguish cumulative usage from real-time speed, then compare server and app attribution. Finally, verify routing by keeping the network fixed, comparing before-and-after readings, and checking request records. Available statistics may vary by device; use the fields shown on your screen, and don’t treat app identification as a complete record of system traffic.
Understanding the readings: uploads, downloads, and speed
Before checking Shadowrocket’s Data tab, determine whether a figure shows cumulative bytes or data transferred per unit of time. Upload is data sent from your device; download is data received by your device. The distinction is based on your device’s perspective, not on who created a file. Loading a webpage usually involves uploads too, since requests, acknowledgments, and other communications must be sent.
Cumulative usage is usually shown in units such as KB, MB, or GB; a reading marked /s is a transfer rate. A 20 MB increase in cumulative downloads does not mean the download speed was 20 MB/s. If the page shows bytes per second while a speed test reports bits per second, the theoretical conversion is 1 byte = 8 bits. For a meaningful comparison, use the same sampling period and unit convention.
Statistics also depend on when counting starts and what falls within the measurement window. Don’t assume that starting a connection, restarting the app, and manually resetting a counter create the same baseline. Note the time range or reset state shown on the page, and unless the measurement scope is clearly stated, compare only before-and-after readings from the same page and test run. Local Data counters and provider billing may measure different layers, directions, or billing rules, so they can’t be used to estimate your remaining plan allowance.
| What you see | What it can tell you | What it doesn’t prove |
|---|---|---|
| Cumulative downloads increase | Data was received within the measured scope | The destination webpage finished loading |
| Instantaneous rate drops to zero | Little or no data was transferred during that sample | The server is unavailable |
| Uploads keep increasing | The device is still sending data | A user file is being uploaded |
| Local usage differs from the bill | The two measurement methods need to be compared | Either side is necessarily counting incorrectly |
Per-server readings: check the egress, not all traffic
Per-server totals help answer, “Which servers have changing counters?” Selecting a server on Home shows the current selection for the relevant proxy. In Config, however, rules determine whether requests use DIRECT, a proxy policy, or another configured policy. So if the selected server shows little change, that doesn’t mean all network requests failed; traffic may be going direct or using another policy.
This sequence illustrates how routing works; it doesn’t mean every counter measures traffic at the same layer. When checking a server, note its name, address, and port so you don’t mistake two entries with the same name for the same egress. A port is a connection parameter, not a unit of measurement. For example, a configured port of 443 alone does not tell you which protocol is actually in use.
- On Home, check the connection status, selected server, and Global Routing.
- Open Data and record the visible upload and download readings for the server you’re checking, keeping the original units.
- Perform one specific network action, then return to the same statistic and record the change.
- If the change differs from what you expected, check which policy or rule matched the request before switching servers.
Existing connections can also affect the results. After switching servers or changing rules, established connections may not immediately reconnect under the new settings. For a test, end the existing network activity and make a new request. If you need to reconnect, first stop any important transfer. A video that keeps playing after a switch does not prove that the new server is handling that connection.
Per-app readings: distinguish app attribution, domains, and system activity
Per-server statistics show the egress; per-app statistics show the source. They are not two separate totals to add together. The same request can be attributed to both a source and an egress. Use the app view to see “which identifiable source became active during the test” and the server view to see “which egress showed a traffic change.” Compare both within the same time window.
On iPhone and iPad, information available to the tunnel is not the same as app attribution in system battery or cellular settings. Don’t assume Data can list complete upload and download totals for every installed app. If the current page groups traffic by app, first check what its labels mean. If it shows only servers, connections, or domain records, work with those fields instead of looking for a menu that isn’t there.
| View | Question it can help answer | Main limitation |
|---|---|---|
| Server | Which proxy egress has a rising counter? | Doesn’t fully identify the app that initiated the traffic |
| App attribution | Which identifiable source generated activity? | What can be identified depends on the system and the page’s capabilities |
| Domain or destination address | Which network destination did the request access? | The same destination may be used by multiple apps |
| Request and rule records | How did a specific request select its policy? | Must be matched to the test time and destination |
A browser may contact the main domain, image hosts, font hosts, and API domains when loading a page. Other apps may use the same content delivery addresses. Seeing a domain therefore doesn’t prove that only one app uses it. Background sync, system push notifications, and cached content also affect readings: traffic may appear without any action, while reopening a cached page may generate very little.
Takeaway: verify source and egress separately
Start with one new request from a single app to narrow the scope. Then check the destination and matched policy to confirm the egress. Don’t attribute an entire increase in server totals to the app you just opened.
Verify routing with Global Routing and rule records
Before checking a rule, look at Global Routing on Home. Proxy, Direct, Config, and Scene are different modes: Proxy routes through a proxy, Direct connects directly, Config follows the active configuration, and Scene requires checking the selected scene’s settings. To verify a rule in Config, first confirm that Config is active; an enabled connection alone doesn’t confirm it.
The examples below are minimal illustrations of the syntax, not instructions to replace your current configuration. example.com is a sample domain; 192.0.2.0/24 is a documentation-only address range, not a destination for real connectivity tests. Save your current configuration before making changes, and confirm that any policy name you use actually exists.
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIXmatches a domain and its subdomains. The main page and its resource domains may match different rules.IP-CIDRmatches a destination IP range. In this example,no-resolvemeans the IP rule won’t trigger an additional domain lookup; it does not mean the connection requires no DNS at all.GEOIPmatches based on the geographic classification of the destination IP in the database. It does not determine location from a website’s display language or domain suffix.FINALhandles requests that didn’t match earlier rules. When troubleshooting, check both the rule you expected to match and whether the request fell through to the final rule.
Rules are generally checked in configuration order. An earlier match may prevent later rules from handling a request. If Data shows only traffic changes, you can’t infer which specific rule matched. Check the app’s request or log records against the test destination, time, matched rule, and actual policy. The location of these records depends on the current interface; a statistics row is not a rule-match log.
A repeatable test: compare changes, not totals
For a short test, use one foreground app on the same network, with the same server selected and the same configuration. Pause other active downloads and sync tasks, while allowing that system background traffic may continue. The goal isn’t to make the device completely silent, but to define the request and time window clearly enough to compare with the records.
- Record the conditions: Note whether you’re on Wi-Fi or cellular, the Global Routing mode, active Config, server entry, and connection status. Don’t update the subscription yet.
- Record the baseline: Write down the upload and download readings for the statistic you’re checking in Data. You can reset it if the page offers that option, but comparing before-and-after readings doesn’t require a reset.
- Make a new request: Open a page whose domain you can verify, note the time, and observe for about 60 seconds. This is just a test window, not a performance benchmark.
- Record the end reading: Check the same statistic and confirm that the measurement scope is unchanged, with no reconnect or network switch during the test.
- Cross-check: Match the egress in the request record to the change in Data. After changing one setting, make a new request and test again.
For example, if a server’s download reading starts at 120 MB and ends at 128 MB, the increase is 8 MB. This is a calculation example, not a measured result, and it doesn’t mean the webpage was 8 MB. If background activity occurred during that period, the change includes that traffic too. If readings are rounded to whole MB, a small request may not cause a visible change right away.
Takeaway: change one condition at a time
First verify the egress with the configuration held constant. Then change one rule and make a new request. Don’t update the subscription, switch networks, and change servers in the same test; otherwise, you won’t know which change caused a different reading.
A subscription update may change server entries, while a change to Config may alter routing. Keep both separate from the test. If you need to update your existing subscription, finish the update and check the selected entry again before recording a new baseline. Don’t assume that statistics for servers with the same name before and after an update are one continuous set of readings.
Common questions about traffic readings
A webpage loads, but server traffic barely increases. Why?
First check Global Routing on Home, then see whether the request used DIRECT or another policy. Make a new request to rule out cached content, and confirm you’re checking the intended server rather than another entry with the same name. A webpage loading by itself doesn’t prove it went through the currently selected server.
Why do upload and download readings change when I haven’t opened an app?
Keep the network conditions unchanged and record a short idle period, then compare it with a single foreground action. Background sync, system communication, and existing connections may continue transferring data. Use destination addresses and timestamps to narrow down the source; a change in total usage doesn’t prove that a particular app is uploading a file.
Why can’t I find per-app statistics?
First check which groupings the current Data page actually provides; don’t mistake a server list for an app list. If there’s no app attribution field, use one foreground app, a fixed time window, and request records to observe traffic. Read system usage statistics according to their own measurement method, rather than subtracting them directly from tunnel totals.
Why does the page still show an error when Data has increased?
An exchange of bytes only shows that communication occurred. Check the error and policy for the failed request, then review destination reachability, DNS, and connection parameters. Handshakes, error responses, and retries can all increase traffic, so activity alone doesn’t prove that a request succeeded or that the connection is performing normally.
After troubleshooting, keep only the information needed to reproduce the issue: test time, network type, routing mode, destination domain, egress policy, and change in readings. Before sharing diagnostics, redact subscription URLs, access tokens, passwords, and private keys. Include only the relevant portions of screenshots or logs; there’s no need to publish your full configuration.