Data is a way to monitor traffic, not a provider’s billing statement, and it can’t prove on its own that a specific rule matched. This guide is for users who already have their own provider and subscription and have connected successfully. It explains server vs. app attribution, upload vs. download, and cumulative totals, then shows how to verify routing with a repeatable test and connection logs. Compare changes before and after a test—not just the total.
1. Data Tracks Traffic, Not Your Plan Allowance
Shadowrocket’s Data page shows network activity recorded by the app. Check the connection status in Home, then open Data to view the statistics. These figures cover only activity within the relevant recording scope. Traffic sent while disconnected, traffic that doesn’t enter the tunnel, and activity handled through another system route may not be included.
Upload is data sent from your device; download is data received by your device. Browsing the web also uses upload: requests, headers, and interaction data all have to be sent. An upload reading doesn’t mean a file is being uploaded, and a download reading doesn’t mean the entire page has finished loading.
This sequence explains what to check and in what order; it isn’t a diagram of the app’s internal implementation. Rules determine where a connection goes, while statistics show how much data it sends and receives. A connection may exchange a small amount of data before failing, so an increase proves only that activity occurred—not that access succeeded.
2. Server vs. App Views: Don’t Add Them Together
The server view shows how much traffic a particular server entry handled. The app view shows which source the traffic is attributed to. These are two ways of organizing network activity, not separate sets of traffic. Don’t add the server total to the app total to estimate your device’s overall usage.
| View | What it can help answer | What it can’t establish on its own |
|---|---|---|
| By server | Which server entry’s upload or download count increased during the test? | The total alone can’t show which rule matched a specific domain. |
| By app | Which identified sources generated the most traffic? | It can’t establish that every connection from an app used the same outbound route. |
| Upload and download | Did this action mainly send or receive data? | These figures aren’t the same as file size or the allowance deducted by a provider. |
| Cumulative total | How much activity has accumulated in the current statistics scope? | Past traffic can’t all be attributed to a configuration you just changed. |
Use the groups and identification results actually shown on the current Data page to determine app attribution. Apple’s network tunnel doesn’t guarantee that every connection will have a clearly identified app name. Don’t force unattributed sources, system processes, or combined records into a specific app category. If the current page doesn’t provide an app grouping, don’t treat a domain list as an app list.
An app may request data from a login endpoint, an image domain, and a content delivery domain at the same time. Those connections may match different rules. So “this app downloaded a lot of data” doesn’t mean “all of this app’s traffic went through one server.” To verify routing, check the destination and actual outbound route in the connection records.
How to check: Use server traffic changes to identify the outbound route, then confirm the destination in connection records
First, identify the server entry whose traffic increased during the test. Then check the destination domain, matched rule, and actual policy for the same time period. Attribute the increase to your test request only when the time, destination, and outbound route line up.
3. Check Global Routing Before Testing Rules
Check the current mode under Home → Global Routing. The Proxy, Direct, Config, or Scene selection affects how traffic is routed. To test rules in a configuration file, confirm that Config is selected and check which file is active in Config. Editing a file without selecting it won’t make the statistics reflect that file’s rules.
- Proxy: Traffic is handled in proxy mode. An increase in server traffic in this mode doesn’t prove that a rule in your configuration file matched.
- Direct: Traffic is handled in direct mode. If proxy server traffic hasn’t increased, that doesn’t necessarily mean the connection or statistics are broken.
- Config: Traffic is routed according to the active configuration. Check rule order, policy names, and fallback rules to understand the outbound route.
- Scene: Routing behavior depends on the scene settings. Confirm which scene is active before testing; the server name selected on the Home screen isn’t enough.
The configuration examples below explain what to check; they aren’t intended to replace your existing configuration. example.com and 192.0.2.0/24 illustrate syntax and don’t provide a working service. To confirm the final outbound route for PROXY, also check the currently selected server or policy group.
Check rule matching
- DOMAIN-SUFFIX
DOMAIN-SUFFIX,example.com,PROXY- IP-CIDR
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve- GEOIP
GEOIP,CN,DIRECT- FINAL
FINAL,PROXY
Rules are evaluated in order; FINAL is the fallback. no-resolve means the IP rule won’t trigger an active domain lookup.
Check the test setup
- Home → Global Routing
- Select Config when testing configuration rules.
- Config
- Confirm which configuration file is active and review its rules.
- Settings → On Demand
- Check whether On Demand conditions affect the connection during the test.
- Home
- Confirm the server and any relevant policy group members actually selected.
Change only one condition at a time. Don’t combine a routing change, server switch, and automatic connection behavior in the same test.
4. Check Traffic Changes with a Short Test
A useful comparison requires the same statistics scope. Note the current values, perform one action, then calculate the difference. You don’t need to clear historical data for every test. If you use a reset option available in the current interface, save any readings you need first and note when you reset. Don’t assume that switching servers or reconnecting will clear cumulative totals.
- Record a baseline: In Data, note the target server’s upload and download readings and the time. Check the connection status in Home and the current mode in Global Routing.
- Reduce background activity: Pause large file transfers, video playback, and sync tasks. Allow for necessary system activity; background noise won’t disappear completely.
- Perform one action: Open a page you’re authorized to access and can test repeatedly, then wait for it to finish loading. Record the domain you visited and the start and end times.
- Calculate the change: Return to Data and subtract the baseline from the final reading. Use the same entry, direction, and unit for both values.
- Cross-check: If connection details or logs are available, look for the matching time period and check the destination, rule, and policy. If there isn’t enough information, keep the conditions unchanged and test again.
Here’s an example of the calculation, not an actual product measurement. Suppose a server’s download reading rises from 120 MB to 126 MB, and its upload reading rises from 8.0 MB to 8.2 MB. The displayed increases are 6 MB and 0.2 MB, respectively. These are traffic changes recorded during that period; don’t assume the webpage itself was exactly 6 MB.
Download increase = 126 MB - 120 MB = 6 MB
Upload increase = 8.2 MB - 8.0 MB = 0.2 MB
Conditions for comparison = same entry + same statistics scope + same unitSmall requests may not show an immediate change if displayed values are rounded. Caching can also reduce how much data is transferred on a repeat visit. If the second load is noticeably faster and traffic barely increases, check whether the content came from cache before concluding that a rule failed. Page redirects, images, and background requests may also contact other domains, so check the actual connections.
5. Common Traffic Questions: Check the Statistics Scope First
Why does the page load without an increase in server traffic?
First, check whether Home → Global Routing is set to Direct or whether a DIRECT rule matched in Config. Make sure the page wasn’t loaded from cache, and check whether a different server or policy group member was used. Test with a new, repeatable network request instead of simply refreshing an existing page.
Why does the download reading keep rising when I’m not doing anything?
System sync, incoming messages, background refresh, and ongoing media connections can all send or receive data. Stop any identifiable transfers, then monitor changes over a fixed time window and check the connection records for that period. Don’t use the cumulative total alone to identify which app is transferring data.
Why don’t the app and server totals match?
Check that both views use the same statistics scope, reset time, units, and grouping criteria. App attribution may be incomplete, and direct traffic doesn’t count as traffic through a proxy server. Compare only values from the same time period; cumulative totals with different scopes aren’t suitable for direct comparison.
Can I still compare a server’s readings after updating a subscription?
First, verify the entry’s actual server address, port, and protocol in Home. Entries with the same name may have different configurations, and an update may change how traffic is attributed. Record a new baseline before testing; don’t assume that entries with the same displayed name before and after an update use the same outbound route.
Another common cause is an automatic condition changing the connection state. Go to Settings → On Demand to review the active connection conditions, and note whether the network switched between Wi-Fi and cellular during the test. On Demand controls when a connection is triggered; it doesn’t assign app labels to traffic. When troubleshooting, separate “whether the tunnel is connected” from “which app the traffic is attributed to.”
6. Minimum Evidence That a Routing Rule Worked
Data is useful for quickly spotting what’s increasing; connection records help explain why traffic took a particular route. To use both, keep the destination and routing conditions fixed, then verify the actual outbound route. A server appearing first in the statistics list doesn’t prove that every request went through it.
- Same destination: Record the actual requested domain or IP, not just the page title. Check redirected addresses and resource domains separately.
- Same conditions: Keep Home → Global Routing, the Config file, and the server or policy group selection unchanged throughout the test.
- Matching evidence: The rule and policy in the connection records match your expectations, and the corresponding Data increase lines up with the test time.
- Repeatable result: After accounting for obvious background transfers and caching, repeat the test and confirm the same outbound route.
Troubleshooting takeaway: Check the matched rule before explaining traffic usage
If the outbound route isn’t what you expected, first check Global Routing and rule order. If the route is correct but traffic usage differs, check the statistics scope, caching, and counting method. Don’t change DNS, protocols, and multiple rules at once to explain a single cumulative reading.
For help troubleshooting connection failures, see Troubleshooting. For guidance on reviewing configuration files and diagnosing issues, see Advanced Troubleshooting. Base these checks on your own existing configuration and service; traffic totals aren’t a substitute for verifying connectivity.