Data shows traffic recorded by Shadowrocket. It is not a cellular billing statement and cannot, on its own, prove which policy a website used. For users who already have their own provider and subscription and can connect, this guide explains the difference between server and app statistics, then walks through a repeatable check: record a baseline, make a request, compare the change, and verify the rule. Available statistics may vary by Apple platform and interface; draw conclusions only from what the current screen actually displays.
1. Separate Cumulative Traffic, Live Speed, and Billed Usage
Shadowrocket is a paid client for Apple platforms, distributed through the App Store and primarily used on iPhone and iPad. You can verify the developer, Shadow Launch Technology Limited, and app ID 932747118 on the product page. Check the App Store listing for system requirements. Figures in Data are observations recorded by the client; they do not replace billing records from a carrier or a service you already use.
When checking a row, first confirm its name, unit, and reporting scope. Upload usually means data sent out from the device; download usually means data received by the device. Both directions are from the device’s perspective, not the remote server’s. Values shown per second are transfer rates; values shown only in bytes are data amounts. If the interface does not specify “this connection” or a time range, do not assume a cumulative figure represents today’s usage.
Cumulative totals can still rise while a connection appears idle. Background sync, notifications, DNS queries, keepalives, and retries may all generate traffic; without request details, these figures alone cannot tell you which one did. Conversely, a page may load while the download total barely changes if the content came from a local cache.
2. Server Statistics: Track Traffic Assigned to an Outbound, Not Total Phone Usage
When viewing statistics by server, start by matching the entry to the server currently selected in Home. Matching names do not guarantee matching connection settings. When comparing records, also check the address, port, and actual selection, especially after renaming a server, switching servers, or updating a subscription. Server-level statistics answer “How much traffic did the client assign to this outbound?”—not “How much data did every app on the phone use?”
| What You’re Looking At | What You Can Conclude | What You Can’t Conclude Directly |
|---|---|---|
| Upload increase for a server | More data was sent to this outbound within the reported scope | All of the increase came from foreground apps |
| Download increase for a server | More data was received through this outbound within the reported scope | The increase matches the stated size of a particular file |
| A previous server still has a cumulative figure | The page still retains historical statistics for that entry | Current requests are still using the previous server |
| No change in a server’s statistics | No visible increase for that entry during the observation period | The request must have used DIRECT, or the connection must have failed |
A request routed through DIRECT does not pass through a proxy server, so a proxy server’s figures should not be treated as a total for direct traffic. Also, a page total may cover a different scope from an individual server entry. Compare or add figures only after confirming that the time range, filters, and reset points match.
3. App Statistics: Check What Can Be Identified Before Interpreting Usage
App and server views group traffic in different ways: the former attempts to answer “Which source generated this data?” and the latter “Which outbound carried it?” An app can contact multiple domains, with some requests going direct and others through a proxy. Its cumulative total therefore does not have to match the total for any one server.
On iPhone and iPad in particular, network traffic visible to a tunnel should not be treated as complete process identity information. If the current Data screen has no app list, don’t look for a universal “by app” switch that may not exist. If it does show app statistics, rely only on the identification results actually displayed. Don’t assign unidentified or unclear records to whichever app you just opened.
- An app name isn’t a domain: An app may connect to separate domains for sign-in, images, video, telemetry, and more. Checking only its main website can’t account for all its traffic.
- Foreground apps aren’t the only source: Other apps may sync in the background while you test in a browser. Keep the test window short and observe the idle baseline.
- Traffic attribution isn’t billing: App data, proxy transport overhead, and system cellular statistics may be measured at different layers. Their figures do not have to match byte for byte.
- Missing doesn’t mean zero: An app may be absent because attribution or visibility is limited. That does not prove the app wasn’t online.
To check whether an app used cellular data, also review its statistics under Settings → Cellular and confirm the system’s reporting period. System cellular figures exclude Wi-Fi usage. Interpret Data according to the connection state and the scope shown on screen; the two are not the same statement.
4. Check PROXY or DIRECT: Start with the Routing Mode, Then Verify the Match
Data shows results; Global Routing determines how requests are routed. To troubleshoot rules, go to Home → Global Routing and check the current mode, then open Config and verify which configuration is active. Proxy and Direct are the basic modes for routing through a proxy or connecting directly. Config routes traffic according to its rules. Scene must be assessed using the selected scene’s specific settings; its name alone doesn’t mean it works like Config.
This minimal snippet illustrates rule order; it is not a complete configuration. example.com is a sample domain, not a substitute for checking your actual destination. PROXY also requires an existing, working proxy outbound to forward traffic.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,DIRECTHow to Read the Rule Snippet
- DOMAIN-SUFFIX
- example.com,PROXY: Matches this domain and its subdomains.
- IP-CIDR
- 192.168.0.0/16,DIRECT,no-resolve: Matches the specified address range without actively resolving a domain for this rule.
- FINAL
- DIRECT: Connects directly if none of the preceding rules match.
Rules are evaluated from top to bottom. This snippet is for illustration only; save the original configuration before making changes.
Check the Runtime Conditions
- Home → Global Routing
- Test rules using Config, and check whether a scene switch is in effect.
- Config
- Make sure the selected file is the one containing the test rules.
- Settings → On Demand
- Check whether automatic connection conditions could affect the tunnel during the test.
On Demand connects according to conditions; it does not prove that a website used PROXY or DIRECT.
The strongest evidence is the rule matched by the specific request and its actual outbound. If the current interface provides connection or request details, locate the same request by domain, destination address, and time, then verify the matched rule and policy. A server counter increase is supporting evidence only, since other requests may have used that server at the same time.
5. Run a Traffic Check You Can Verify Using Before-and-After Readings
You don’t need to clear all historical statistics first. Record the readings before and after the test to preserve reference data and avoid relying on whether the interface offers a reset button. This procedure uses only destinations you already have access to; there’s no need to switch or add a service.
- Keep conditions consistent: Choose Wi-Fi or cellular and don’t switch networks during the test. Pause large transfers, then note the current server in Home and the Global Routing mode.
- Record a baseline: Open Data and note the target server’s upload and download figures and units. If app statistics are available, record the relevant app as well. Wait about 30 seconds and check for any noticeable increase while idle.
- Do one thing at a time: Open one target webpage or read a test file you already have. Don’t run multiple tests at once. Record the start and end times, and note any domains reached after redirects.
- Check the change: Wait for the page’s statistics to refresh, then subtract the starting value from the ending value. If the display is rounded, a small request may not show an immediate change; don’t assume that means zero traffic.
- Cross-check the result: Consider the target request’s matched rule, actual outbound, and counter change together. If you need to change the configuration, adjust one condition at a time and repeat the test. Restore the original settings afterward.
6. Common Questions About Traffic Readings
A webpage loads, but the server counter doesn’t increase. Does that mean it didn’t use a proxy?
First rule out cached content, then check Home → Global Routing and the active rules in Config. If the request matched DIRECT, it’s normal for the proxy server counter not to increase. If it matched PROXY, make sure you’re checking the right server entry, the readings have refreshed, and the request was actually sent again.
Why is Data usage higher than the downloaded file size?
Pause other transfers and repeat the test using before-and-after readings. A file’s stated size describes its contents, while the statistics may also include other requests, request headers, connection maintenance, or retries. Check the page’s reporting scope to see what it counts; don’t use a fixed ratio to work backward to the file size.
I switched servers, but the old one still has a figure. Should I delete it?
First distinguish a cumulative total from new traffic. Note the old entry’s reading, wait, and make one clearly identifiable request, then check for a change. If the old figure doesn’t increase, it’s usually just a historical reference. Don’t delete an existing server or configuration just to make the page show “zero.”
System cellular statistics and Data are far apart. Which one should I use for my plan?
Use your carrier’s billing records for plan usage. First check the reporting period under Settings → Cellular, then account for Wi-Fi usage, different reset times, and background data. Data helps troubleshoot traffic distribution visible to the client; it doesn’t report your remaining plan allowance.
The target app isn’t in the app list. Can I assign traffic to it by domain?
Not reliably. A shared domain may be used by multiple apps, and a webpage may load third-party resources. Repeat a short test with one app at a time. If the interface still can’t identify the source, leave it as “unclear” rather than assigning the entire server increase to that app.
7. Keep the Reporting Scope and Hide Sensitive Details in Troubleshooting Notes
For a reproducible record, include the test time, network type, Global Routing mode, active Config, target domain, and before-and-after readings for the same entry. If you need to explain the issue to your own service provider, add the observed error and the policy that actually matched. A cumulative total without a time window usually isn’t enough to identify a single request.
- Note the unit and display precision, such as MB or KB/s. Don’t mix data amounts with transfer rates.
- State whether you switched networks, servers, or configurations during the test, and whether an automatic reconnection occurred.
- Hide the full URL of any existing subscription, along with tokens, passwords, and other credentials. Traffic diagnostics don’t require sharing them.
- Don’t infer that one successful request means an entire app always uses the same route. Check different domains within the app separately.
State the conclusion precisely: “During this test window, the request matched a specific rule, and the corresponding outbound showed an increase.” Don’t claim “Data has a number, so all traffic used a proxy.” Record rule evidence separately from traffic statistics to distinguish routing issues from caching, background usage, and differences in reporting scope.