How to Read Shadowrocket Data Usage: By Server and by App

What Data tracks: client traffic vs. service usage

Shadowrocket Data shows traffic handled and recorded by the client. Once connected, readings increase only for requests that follow a covered processing path. Cellular usage in your device settings, device usage recorded by your router, and usage reported by your existing service account follow different measurement methods; their totals are not expected to match.

This flow helps explain where traffic is counted; it does not mean Data can identify the complete source of every request. Background system tasks, shared network processes, and platform permission limits can all affect attribution. If an app name is missing, that does not prove the app was offline. Likewise, a server's reading may stay unchanged because a request was cached or matched DIRECT.

• Client total: Shows traffic recorded locally. The tracking period starts when that record is created or was last reset.
• System usage: Measured by device, app, or network type, and may include traffic that did not pass through Shadowrocket.
• Service usage: Determined by the measurement rules of your existing service. Billing periods, usage multipliers, protocol overhead, and reporting delays may affect the total.

Upload, download, and total usage: check the units first

Read upload and download from the perspective of your device: sending requests or uploading attachments counts as upload; receiving web pages or downloading files counts as download. Web browsing usually uses more download, while photo uploads or cloud backups can increase upload. Do not reverse these directions based on what the server receives or sends.

For example, if download usage rises from 48 MB to 60 MB, about 12 MB was transferred between the two observations. That does not mean the current speed is 12 MB/s. If the change occurred over 30 seconds, the average rate for that period was about 0.4 MB/s, but this is not the instantaneous rate at every second. This is a reading example, not a performance benchmark.

By server vs. by app: don't add the two views together

Open Data from Home, then check whether the current view groups usage by server or by app before reading an entry. Menus and available dimensions vary across platforms. If your platform has no app view, troubleshoot using the available server readings and connection records; do not assume another platform's menu is a required option.

A transfer can be attributed both to the app it came from and the server it used. The two views show the same related traffic from different angles; they are not separate usage amounts, so don't add them to get a total. They may not match exactly either: unidentified sources, whether DIRECT traffic is included in a view, and refresh timing can all cause differences.

• When a browser has several tabs open, one app entry may include multiple domains and connections.
• In-app web views and background network tasks may run through shared components, so they may not appear under the app name you expect.
• An increase under an app only shows that traffic was attributed to that app. It does not by itself prove that every request used PROXY.

When does total usage start? Set a baseline you can check

Don't assume totals start at midnight, on the first day of the month, or whenever a connection is enabled. Use the tracking period shown in the current view. If the interface does not show a start time, don't treat the reading as an exact amount for a particular day. Disconnecting, leaving the page, or changing servers does not necessarily reset all statistics.

1. Record the current readings. Go to Home → Data and note the current view, entry name, upload, download, and observation time. For a single troubleshooting test, comparing before and after is enough; you don't need to clear the history.
2. Pause test traffic. Stop downloads, video playback, and cloud sync; disconnect if needed. Otherwise, readings may become nonzero again as soon as the reset is complete.
3. Check what will be cleared. In Data, find the clear or reset option available in the current interface. Read the confirmation and check whether it affects one entry, the current view, or all records. Button names and locations vary by platform. Deleting a server or Config is not a way to reset usage.
4. Verify the result. Return to the relevant view and confirm that the target entry's baseline has reset. Then check the other view to see whether it was cleared too; don't assume the two dimensions are linked.
5. If there is no reset option, compare the difference. Record the starting and ending readings, then subtract the starting value from the ending value. This also gives you a repeatable test period.

Check routing with Data: start with Global Routing, then compare usage changes

Data provides evidence about traffic attribution and volume, but it cannot replace rule-match records. First, check the mode under Home → Global Routing: Proxy uses the proxy route, Direct connects directly, Config follows the active configuration, and Scene follows the configured scene. To troubleshoot Config rules, select Config and confirm the expected configuration is enabled under Config.

The examples below use reserved example domains and do not represent real services or need to be added to your everyday configuration. Rules are evaluated in order: an earlier match can prevent later rules from taking effect.

DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

1. In the current Config, check which rule should match the target domain or IP address, and whether a broader rule appears before it.
2. Note the starting value for the expected server in Data. Close unrelated apps and choose an accessible test address you already have access to.
3. Reconnect for the test and perform one clear action, such as downloading a known-size test file of your own. A browser cache hit is not suitable for verifying network transfer.
4. Return to Data and compare the change for the same entry, then check the connection record for the destination, matched rule, and final policy. Port 443 is commonly used for encrypted connections, but that alone does not show whether traffic went through PROXY.
5. If you changed a rule, end the old request before trying again. Existing long-lived connections may keep using their original route; their later traffic does not show the immediate effect of a new rule.

Common questions about unexpected readings

Keep a concise troubleshooting record

For follow-up checks or troubleshooting, record when the test happened, which view and entry you checked, what you did, and how much the reading changed. This is more useful than saving a total alone. Don't include subscription URLs, authentication details, or full server credentials in your notes. A subscription update may change entry names or available servers, so verify that you're comparing the same entry before and after an update.

• Environment: Device platform, Wi-Fi or cellular, and whether the connection was enabled.
• Routing: Current Global Routing selection, whether Config is the expected configuration, the target rule, and the final policy.
• Period: Start and end times, whether the data was reset, starting and ending readings, and units.
• Action: Run one test app, record one clear request, and note whether you ruled out caching and old connections.
• Result: Whether the server increase, app increase, and connection record match.

Data helps answer “what changed in traffic during this period?” It cannot by itself tell you “how much usage remains on my service?” or “did every app always follow the rules?” Save the usage difference alongside the rule result for the specific connection to make your conclusion verifiable.