This guide is for users who have imported their own subscription into Shadowrocket and want to check where traffic is going. First distinguish server totals from app attribution, then use a consistent measurement window and cross-check a single request against its matching rule and the change in traffic. Data shows cumulative usage, not real-time speed, and is not a substitute for your provider’s bill. App attribution is limited to the information available in the app and the system.
1. Start with what the Data figures measure
When you open Data, don’t focus only on the largest number. First check whether an entry represents a server, a connection destination, or an app; whether the figure is upload, download, or total; and when the measurement period began. Even if two places show MB, their values are not directly comparable if they cover different items or time periods. Available groups, fields, and reset controls depend on the app’s current interface.
Upload generally means data sent from your device; download means data received by it. Web browsing also sends requests, connection negotiations, and acknowledgments, so nonzero upload does not mean files are being actively sent. Cumulative usage is the amount transferred over a period of time. Speed includes a time unit, such as KB/s. Treating a cumulative total of 20 MB as a current speed of 20 MB leads to the wrong conclusion.
To measure traffic generated by an action, subtract the starting value from the ending value; don’t compare two cumulative totals. If you reset statistics, change the measurement scope, or reconnect during the test, record a new baseline. In-app counters, system cellular usage, and provider bills each have different measurement boundaries. A mismatch alone does not indicate a problem.
2. Server totals show the route; app stats show the source
Server totals answer: “Which server entry handled the traffic?” If multiple apps use the same server, their traffic is combined. A single app may also access multiple destinations and use different outbound routes depending on the rules. An increase in server traffic alone cannot prove that all requests from a particular app went through that server.
App-level stats aim to answer: “Which app generated this traffic?” But an app is not the same as a domain: one app may connect to different domains for content, images, sign-in, and push notifications, while multiple apps may access the same domain. Don’t treat the cumulative traffic for one destination as an app’s complete usage.
This distinction matters especially on iPhone and iPad: packet information available to a VPN tunnel is not the same as complete system process information. If the current Data screen has no app attribution field, you can’t infer an app-by-app ranking from server names. If the interface shows unidentified or unattributed entries, keep that uncertainty in mind. To check each app’s cellular usage, go to system Settings → Cellular and check the system’s measurement period. These figures do not include an app’s Wi-Fi usage.
| What’s being measured | What it can tell you | What it can’t prove on its own |
|---|---|---|
| Server entry | Traffic change for this entry during the current window | That every request from a particular app used this server |
| App attribution | Traffic sources identifiable within the available data | That traffic from every app on the device is fully attributed |
| Destination domain or IP | Where a request connected | That a request definitely came from a particular app |
| System cellular usage | Cellular data used during the system’s measurement period | The same app’s usage over Wi-Fi |
3. Use a consistent window for a repeatable traffic test
Before testing, check Home to confirm the connection is established, then note the current Global Routing selection and the enabled profile in Config. This guide assumes you already have your own server and subscription; you don’t need another connection service to view statistics. Don’t update your subscription or switch servers during the test, since changes to entries with the same name can affect the comparison.
- Reduce background activity: Pause large transfers, video playback, and cloud syncing. Avoid using other apps in the foreground, but don’t assume this will eliminate all background traffic.
- Record a baseline: In Data, note the target server’s cumulative upload and download values and the time. Keep existing records; there’s no need to clear all statistics before every test.
- Trigger one action: Open just one app and visit a known page or perform one specific action. Don’t refresh several pages at once. Observe for about 60 seconds.
- Record the end values: Return to Data and read the same entry using the same measurement scope. Calculate the upload and download increases separately.
- Check the request: Use the available connection records to verify the destination domain, matched rule, and outbound. If there isn’t enough detail, draw a more cautious conclusion; don’t treat the traffic increase as the only evidence.
- Repeat once: Run the test again without changing settings. The second run may use cached data, so its byte count won’t necessarily match the first exactly.
To compare two settings, change one variable at a time. For example, keep the server the same and switch Global Routing from Proxy to Config, then establish a new test connection. If you change the server, DNS, and rules all at once, you won’t know which change caused the difference.
4. Match traffic changes to rule hits
In Home → Global Routing, Proxy, Direct, Config, and Scene represent different routing modes. Proxy is useful for testing a proxy route, while Direct provides a direct-connection comparison. Config routes traffic according to the rules in the current configuration. Scene depends on the settings for the selected scene; don’t assume it always means proxy or direct routing.
To verify rule-based routing, select Config and confirm which file is enabled in Config. Rules are generally evaluated in order, so an earlier match can determine the outcome; FINAL is the fallback. Seeing a DOMAIN-SUFFIX rule in the editor doesn’t prove that this connection matched it or that it takes precedence over other matching rules.
Record before testing
- Connection entry
- Home
- Routing entry
- Home → Global Routing
- Routing mode
- Config
- Configuration check
- The file currently enabled in Config
Record the actual selection; don’t rely on what you remember setting.
Example rule meaning
- DOMAIN-SUFFIX
- example.com,PROXY
- IP-CIDR
- 192.0.2.0/24,DIRECT,no-resolve
- FINAL
- DIRECT
- Match order
- Top to bottom; the matching rule’s policy is applied
The example uses reserved domains and documentation address ranges to explain the syntax; they are not test targets.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,DIRECTIn the example, example.com and its subdomains match PROXY; the documentation address range matches DIRECT. no-resolve means this IP rule won’t trigger an additional domain lookup. All other requests fall through to DIRECT. This is only a rule snippet, not a complete configuration. In practice, check that the policy names are available in your current configuration and match your intended routing.
How to verify: match each request with a set of evidence
If a destination is expected to use PROXY, check the rule matched by that request, the actual outbound, and the traffic increase for the corresponding server. If the cumulative figure increases but you can’t tie it to a request, repeat the test with a single app before changing the entire ruleset.
5. Why traffic figures may differ from expectations
Differences most often come from measurement boundaries, not failed rules. The device may count data at one processing layer, while the provider bills on the server side using its own methodology. Encapsulation, connection negotiation, retransmissions, upload and download billing policies, and measurement windows can all contribute. HTTPS commonly uses TCP port 443, while HTTP/3 commonly uses UDP port 443. The same port doesn’t identify the app, nor does it mean every request uses the same transport.
- Page cache: If a page loads from the local cache, it may only make a small request to check for updates. A change on screen doesn’t mean all the content was downloaded again.
- Background activity: Notifications, syncing, and other connections can keep increasing a server’s cumulative total while the app under test is idle.
- Direct traffic: Requests using DIRECT shouldn’t be expected to appear under a proxy server entry. Whether they appear in another total depends on the measurement scope shown in the current interface.
- Existing connections keep their route: After you change rules, an established connection may continue using its original route. End the test action and establish a new connection before checking the new rules.
- Counting and refresh behavior: Rounding, refresh intervals, resets, or changes to the measurement window can distort comparisons involving small amounts of traffic. Rule these out before calculating the difference.
- Changed entries: After you update your own subscription, server names, addresses, or groups may change. Records with the same name from before and after an update may not belong on the same timeline.
On Demand can also affect the observation window. If the connection disconnects or reconnects automatically during a test, check the trigger conditions in Settings → On Demand and note the actual connection state. On Demand controls connection behavior; it doesn’t show that a request matched PROXY or DIRECT. Check Global Routing and the request records to determine its route.
6. Common traffic questions and what to check
The app is open, but why hasn’t server traffic increased?
First check whether the page loaded from cache, then check the connection status and Global Routing in Home. If the current mode is Direct, or a Config rule sends the destination to DIRECT, no increase under a proxy server entry may be expected. Trigger another network action and check its destination and outbound.
I closed all my apps, but the Data figures are still rising. Are my rules wrong?
Stop other transfers, record the increase over two consecutive 60-second windows, and check for background connections or long-lived connections that are still transferring data. No foreground activity doesn’t prove that traffic is abnormal. Identify the destination and connection before deciding whether to change any rules.
Why don’t the app totals add up to the server total?
First check the measurement window, network type, and whether you’re comparing upload, download, or total usage. Then check whether app attribution is complete, whether any entries are unattributed, and whether DIRECT traffic is included. System cellular statistics and Data are not expected to match, and you can’t assign the entire difference to a particular app.
I changed the rules, but the traffic still seems to use the old server. Why?
First confirm in Config that the modified file is enabled, then select Config in Home → Global Routing. End the old connection and try again. If the route still doesn’t match, check earlier rules and FINAL. Reconnect if needed, but save your test baseline first so you don’t combine cumulative readings from before and after reconnecting.
A complete troubleshooting record should include the test time, network type, Global Routing selection, enabled configuration, destination request, and upload and download increases. For more help, use the troubleshooting guide to check connections and rules, or consult the glossary for policy keywords. Data is useful for spotting trends and testing assumptions; a routing conclusion should be based on a specific request and its actual outbound.