This guide is for users who have already imported their own subscription into Shadowrocket and want to check where traffic is going. First, distinguish the server and app views; then compare readings before and after a test to identify activity, and cross-check the result against Global Routing and connection records. Data is a client-side view, not your provider’s account balance. A cumulative total alone cannot show which rule handled a request.
What Data measures: direction, total, and speed
Shadowrocket’s Data view shows network activity recorded by the client. Upload is data sent from your device to a remote host; download is data received from a remote host. Both usually increase when you open a webpage: requests, acknowledgments, and app sync also use upload, so uploads aren’t limited to file transfers.
Start by checking the units. KB, MB, and GB indicate data volume; units ending in /s indicate speed. A cumulative download total of 120 MB doesn’t mean a download is still in progress, and a reading of 0 B/s at one moment doesn’t mean no data was transferred earlier. The numbers below are examples for explaining the calculation, not performance test results or billing commitments.
Data isn’t a complete record of all network activity on your device. What it counts depends on which connections pass through the client, what information the system provides, and how the current view groups activity. Don’t expect activity outside that processing path to appear in Data. Its figures also don’t have to match the system’s cellular data totals.
By server: find which exit showed an increase
In the server view, focus on changes in each server’s upload and download totals, not just the row with the largest cumulative figure. Older entries may retain usage from a longer period, while the currently selected server may have no new requests yet. If server names are similar, check the exact entry in Home rather than assuming similarly named servers use the same exit.
- In Home, confirm the selected server and note the current Global Routing mode: Proxy, Direct, Config, or Scene.
- Open Data, find the server you want to check, and note its upload and download readings and the time.
- Perform one specific action, such as opening a test page you can access in your browser, and wait for it to finish loading.
- Return to Data, wait for the readings to refresh, then note the same row and compare the before-and-after values.
For example, if a server’s download total rises from 120 MB to 128 MB, the observed increase is about 8 MB at the displayed precision. This shows download activity on that entry during the observation window; it doesn’t prove that all 8 MB came from the page you just opened. Background sync, requests from other apps, and multiple page resources may all use the same exit at once.
By app: app attribution isn’t the same as destination
The app view answers “which identifiable sources generated traffic?” The server view answers “which exits handled traffic?” They’re different views of the same activity, so don’t add their totals together. One app may contact multiple domains and use both PROXY and DIRECT; one server may carry requests from multiple apps.
App attribution depends on the information provided by the system. If a record has no clear app name, is grouped with other activity, or shows only connection details, don’t identify its source from the domain alone. Shared services, embedded webpage resources, and system background activity may access similar addresses. Data isn’t a per-app audit of all system traffic.
- Check the source: Pause other foreground activity, note the reading for the app you want to check, then refresh once in that app only.
- Check the destination: Compare the server’s change with the relevant connection record. An increase in an app’s row alone doesn’t tell you whether traffic used a proxy or a direct connection.
- Handle missing attribution: If your device doesn’t show an app source, don’t guess or add a name. Use the request time, destination domain, and actual policy result to investigate instead.
- Avoid false conclusions: An app moving to the background doesn’t stop network activity immediately. A small increase may still appear after the test ends.
Cross-check PROXY and DIRECT with Global Routing and rule records
Check Home → Global Routing before interpreting the totals. Proxy uses proxy routing; Direct uses direct connections; Config routes traffic according to the active configuration’s rules; Scene follows the conditions and settings defined by the selected scene. Scene isn’t a fixed “proxy everything” mode. To test rules in a configuration, use Config and confirm that the configuration you want to check is active.
Check Global Routing
- Mode
- Home → Global Routing
- Proxy
- Proxy routing; not for verifying individual routing rules
- Direct
- Direct connections; server traffic increases aren’t a success criterion
- Config
- Uses the active configuration’s rules
- Scene
- Check the active scene’s conditions and routing settings
Keep the mode unchanged during the test so readings from before and after a switch don’t get mixed together.
A minimal rule example
- DOMAIN-SUFFIX
- example.com,PROXY
- IP-CIDR
- 192.168.0.0/16,DIRECT,no-resolve
- GEOIP
- CN,DIRECT
- FINAL
- PROXY
This example illustrates the syntax; example.com is a sample domain. Don’t replace the full configuration you’re currently using with it.
In the configuration’s [Rule] section, each rule must be on its own complete line. Rules are generally matched from top to bottom, and the first match determines the policy. Put FINAL at the end as a fallback. Here, no-resolve means not to trigger a domain lookup for this IP rule; GEOIP checks the destination IP’s geographic assignment, not a region guessed from webpage text or a domain suffix.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYTo check a request, find its time and destination in the connection records, then review the rule that matched, the policy, and the outbound details. If PROXY points to a policy group, also check which server the group actually used. DNS, redirects, and page resources can create additional connections, so one page load may involve multiple policy results.
Bottom line: verify both the rule result and the traffic change
To determine whether a specific request used PROXY, find its match result and actual exit, then use the server’s increase during the same time window as supporting evidence. To verify DIRECT, check the request record as well; a proxy server’s lack of growth alone isn’t enough to draw a conclusion.
Counting and reset timing: save a baseline before testing
Resetting readings can start a fresh observation window, but it won’t fix routing. Disconnecting and reconnecting, switching servers, updating a Subscribe, or selecting a different Config doesn’t guarantee that all cumulative totals will reset. Different views may show totals for different scopes, so confirm what you’re looking at before taking action.
- Save a baseline: Record the time, server name, routing mode, and upload and download readings. For troubleshooting, keep the relevant connection records too.
- Confirm the scope first: If you use a reset option in Data, read the on-screen prompt and confirm whether it applies to the current entry or all statistics. If the scope isn’t clear, compare readings before and after instead.
- Limit background traffic: Pause controllable large transfers and media playback, but don’t assume all background activity stops immediately.
- Use one consistent window: Record readings after completing a test. Don’t update a subscription, switch servers, or change the configuration midway through it.
- Keep your findings: Save the observed change alongside the rule records. Only then decide whether to reset readings for another test.
Resetting the client’s readings won’t reset usage already recorded by your provider or change its billing cycle. Even if both sides count uploads and downloads, differences can result from protocol overhead, retransmissions, where counting occurs, displayed units, and update timing. Align the time range and units before comparing figures, then check the provider’s billing definition. Don’t infer a problem by comparing totals from different billing periods.
Common reading questions: identify the symptom, then retest one thing at a time
A webpage loads, but server totals barely change. Did it bypass Shadowrocket?
Not necessarily. Check Home → Global Routing first, then see whether the request matched DIRECT. A cached page may not download its main resources again, and small requests may be hidden by the displayed precision. Try an action that clearly triggers a new request, then use the connection records to confirm whether it went through the client.
Why does the upload total keep increasing when I haven’t uploaded a file?
Web requests, connection acknowledgments, and app sync can all generate uploads. Pause media playback and controllable transfers, note the readings over a one-minute window, then check the destinations and times of new connections. You can tell whether the increase is normal background activity or app behavior to investigate only by linking it to specific requests.
Why is the old server still showing a small increase after I selected a new one?
Connections opened before the switch may still be active, and a policy group in the configuration may select a different exit. Check when the connection started, which policy matched, and which server it actually used. To isolate a retest, end the current test connections if it’s acceptable to interrupt the activity, then send a new request. Don’t assume every existing connection follows the selection shown in Home.
What should I do if new traffic appears after I’ve closed the connection?
Check the system VPN status and Settings → On Demand to see whether an automatic connection condition re-established the connection. Then check whether the reading simply refreshed late. For troubleshooting, note the original settings before temporarily pausing On Demand, and restore them when you finish so an automatic reconnect isn’t mistaken for ongoing statistics.
The app and server totals don’t match. Which one should I trust?
The two views may group different activity, and unidentified sources or DIRECT traffic can affect the comparison. Check the same observation window, then match requests one by one. If you’re checking your account balance, use your own service’s account records; don’t treat a total in Data as a bill.
Keep a traffic test record you can review
A useful check should answer three questions: which app made what request, which policy the rule assigned, and whether the relevant exit showed a reasonable increase. Use the format below to keep a manual record; the figures are calculation examples, not fixed traffic amounts. Replace the test domain with a destination you can legally access and monitor. Don’t include subscription credentials in your notes.
| Record | Before test | After test or verification result |
|---|---|---|
| Global Routing | Config | Keep Config selected |
| Target server upload | 12 MB | 13 MB, about 1 MB increase |
| Target server download | 120 MB | 128 MB, about 8 MB increase |
| Request result | Record the destination and start time | Check the matched rule, policy, and actual exit |
If you still can’t reproduce the issue, repeat the same action first; don’t change the protocol, server, and rules all at once. Before sharing troubleshooting details, redact subscription URLs, tokens, passwords, keys, and personal browsing records. Data provides clues, not a verdict. To reach a finding you can verify, compare the source, rule, exit, and traffic change within the same time window.