Shadowrocket Data Usage Guide: Reading Traffic by Server and App

1. Understand the two Data views

Shadowrocket’s Data page shows traffic statistics in two views. The server view answers “Which proxy server carried the traffic?” The app view answers “Which apps generated traffic that can be attributed?” They are two ways of looking at the same network activity, so adding them together may count traffic twice.

When you open Data, first check whether the current view is by server or by app, then read the totals in the list. Don’t assume the first item is the server currently in use, or that an app with no separate entry has no network activity. The information the system provides for app attribution, and whether a connection falls within the current statistics, both affect what appears.

In the server view, one app may use different servers at different times. In the app view, one app may also have both direct and proxy connections. So “how much traffic an app used” and “how much traffic a server carried” are not expected to match one-to-one. For a meaningful comparison, use the same time window rather than comparing totals read at different times.

2. Read upload, download, totals, and speed

Upload is data sent outward from your device; download is data your device receives. Browsing a webpage usually involves more download traffic, but sending search terms, request headers, and acknowledgments also uses upload. Uploading a photo usually involves more upload traffic, but the device still receives server acknowledgments and page responses, so the other direction may not be zero.

It’s normal for a file’s size and the increase in traffic statistics not to match exactly. Requests, encryption overhead, connection setup, and retransmissions can add data; caching, compression, and segmented requests can change how much is transferred. Different measurement points may include different layers of overhead, so one figure does not tell you that all traffic is counted in the same way.

Note the difference between uppercase B and lowercase b: B means bytes, while b means bits; 1 B equals 8 b. As a rough bandwidth conversion, 1 MB/s is about 8 Mbps, but account for the difference between MB and MiB, as well as protocol overhead. Data’s cumulative byte count is not a speed test result.

3. Use server totals and before-and-after changes to identify the actual outbound route

Server statistics are best for checking whether a request used the server you expected. Selecting a server on Home only chooses the proxy outbound; whether traffic actually goes through it also depends on Global Routing and the rules. With Global Routing set to Direct, requests connect directly, so don’t expect proxy traffic to keep increasing just because a server is selected.

1. On Home, check the connection status, selected server, and Global Routing. To test rule-based routing, use the Config mode and confirm the active configuration in Config.
2. Open Data and note the target server’s upload and download totals and the time. Pause other downloads, cloud sync, and streaming to reduce background traffic.
3. Perform one repeatable action, such as downloading a file of known size from a webpage you’re authorized to access. Don’t switch servers or change rules at the same time.
4. When the action is complete, return to Data, wait for the figures to refresh, and note the new values. Calculate the change as “after minus before.”
5. Then check the corresponding connection’s destination, matched rule, and actual policy. Server totals provide supporting evidence; an individual connection record confirms what happened to a specific request.

For example, this is a calculation, not a measured result: if a server’s download total rises from 120 MB to 132 MB and its upload total rises from 8 MB to 8.4 MB, the increases during the observation window are 12 MB and 0.4 MB. This shows that the server carried traffic during that window; it doesn’t prove that all 12 MB came from the page you just opened.

4. Use app statistics to distinguish app attribution from routing

The app view is useful for finding traffic from background downloads, autoplay, or sync tasks. Find the app, then compare its upload and download figures over the same window. Traffic attributed to an app doesn’t mean all its requests use a proxy: a page may request its main site, image domains, video domains, and analytics endpoints, each of which may match a different rule.

App names shown depend on the information provided by the system. If an entry can’t be attributed to a specific app, keep that limitation in mind rather than guessing the app from its destination domain. A browser’s total usually can’t tell you which of several open tabs generated the traffic. To check a particular page, use a shorter test window and review the connection to its destination.

• The figures increase while you’re not using the app: Check for background sync, preloading, automatic updates, or media that is still playing. Pause these tasks, then record the change again.
• You open a page, but the figures barely change: The page may have loaded from cache, or its traffic may not be included in the current attribution scope. Check with a new request that clearly requires network access.
• App and server totals don’t match: First align the time range, then check for direct requests, traffic through other servers, and traffic that couldn’t be attributed. Don’t try to force a one-to-one match between entries.

If the expected app entries aren’t shown on your device, that doesn’t necessarily mean the installation is faulty. Check which statistics your platform actually provides. If the app view is limited, you can still verify routing using server totals and connection records.

5. Use Data to check Config routing rules

Data shows changes in transferred traffic, but it doesn’t explain why each rule matched. To check rules, first confirm that Home → Global Routing is set to Config, then review the active configuration in Config. Proxy, Direct, and Scene are different routing modes; results from another mode can’t be used as proof that the current rules file is working as intended.

A complete rule line consists of a rule type, a match value, and a policy. FINAL specifies the fallback policy directly. The examples below illustrate syntax; they are not a routing setup for every network. The IP-CIDR example uses a documentation-only address range to avoid pointing to a real service.

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

Rules are evaluated from top to bottom, and evaluation stops at the first match. DOMAIN-SUFFIX matches domain suffixes; IP-CIDR matches address ranges. In IP-CIDR, no-resolve means the rule won’t actively trigger a domain lookup for that IP match; it doesn’t stop the app from making DNS queries altogether. FINAL handles requests that didn’t match earlier rules, so place it after rules that need to be evaluated first.

1. Use a real destination you’re authorized to access, and place its domain rule before any broad rule that could match first.
2. Save the changes and confirm that the modified Config is active. Close the old page or end the existing connection, then make a new request to avoid interference from an existing connection.
3. Check the destination and matched policy in the connection record, then compare it with the server totals in Data. If DIRECT is expected, a page loading successfully alone doesn’t prove that proxy routing worked.
4. Restore the original configuration after testing. If you were using Scene, note its selection conditions so you don’t mistake a routing change after switching back for a statistics issue.

6. Common issues: mismatched totals and increases after disconnecting

You don’t need to change the protocol, DNS, rules, and server all at once when troubleshooting. Change one thing per test, and record the time, network type, routing mode, before-and-after figures, and connection result. This helps separate background traffic, rule selection, and statistics scope—and makes it easier to reproduce the same conditions later.