How to Read Shadowrocket Data Page Traffic Stats: Per-Server and Per-App Readings

Where the Data page is and what the two sets of readings measure

Open Shadowrocket; Data in the bottom tab bar is the traffic statistics page. The top of the page shows the total for the current period, with upload and download listed separately; details are grouped below, and switching groups at the top of the page toggles between the by-server and by-app views. When the connection switch is off, traffic does not go through the tunnel and the numbers on the page will not grow, so if the readings look frozen, go back to Home and check the connection switch at the top.

The two sets of readings do not count the same thing. By server counts the connection bytes attributed to a given server entry; only connections actually forwarded through that server appear in this column. By app counts the app that opened the connection: as long as the connection went through the tunnel, it is recorded under that entry whether it ended up proxied or direct. So over the same period the two totals usually do not match; the difference comes from connections matched by DIRECT, DNS queries, and connections rejected by REJECT.

Which group to look at first depends on the question you are asking: to find out which server the traffic landed on, look at by server; to find out which app started it, look at by app. Used together, the two groups let you match a given app to a given server.

Units and how to read them: making upload, download, and totals add up

Every reading is split into upload and download. Upload is the bytes your device sent, download is the bytes it received; the two are never merged into one number because they mean different things when troubleshooting: unusual download usually means something is downloading or syncing, while unusual upload is more likely tied to uploads, backups, or heartbeat requests.

Units step up in base 1024 — B, KB, MB, GB — and the display picks the appropriate one automatically, so the same row may show MB at one moment and GB at another. The readings count bytes inside the tunnel, including the extra overhead from encryption and encapsulation, so they are usually slightly larger than the actual content size; downloading a 1 MB file and seeing 1.0x MB is normal.

Overview   ↑ 15.6 MB     ↓ 412.3 MB
By server  Server A      ↑ 12.4 MB     ↓ 386.2 MB
By server  Server B      ↑ 1.8 MB      ↓ 24.9 MB
By app     Safari        ↑ 3.1 MB      ↓ 208.7 MB

The layout above is only an illustration; the numbers are not measured values. In the real list each row also shows its share of the total, which makes it easy to spot the largest item at a glance; reading the share together with the absolute value makes anomalies easier to catch than looking at the total alone.

By-server readings: which server the traffic landed on

Each row in the by-server list corresponds to an entry in the server list on the Home page, with the same name shown there. After you switch servers, new traffic is recorded under the new entry; the old entry's historical readings do not reset automatically unless you clear the readings manually on the Data page or delete that entry.

This set of readings answers two questions directly: whether current traffic is landing on the server you expect, and whether a given server keeps generating traffic when you are not doing anything. The first helps you verify that Global Routing and Config rules behave as intended; the second helps you spot entries you forgot about in your configuration.

If you see an entry you do not recognize, go back to Home and check the server list first. Entry names match Home and normally come from a configuration you imported or a server you added manually; entries do not appear out of nowhere.

By-app readings: which app the traffic came from

The by-app list attributes traffic to the process that opened the connection. Requests to the same domain from different apps are counted separately, so it can answer who is using the traffic — something system-level statistics cannot do: iOS usage stats aggregate by network interface and cannot attribute bytes to a specific app.

The Global Routing mode directly changes how the two sets of readings are distributed. In Config mode, connections matched by rules count toward the corresponding server, while those matched by DIRECT appear only in the by-app list; in Proxy mode all connections funnel into the currently selected server, so the by-server list is basically one row that keeps growing; in Direct mode the by-server readings stop growing while the by-app readings keep accumulating.

When checking whether a rule is matching by mistake, Direct mode is a clean control: switch to Direct and repeat the same action — if the by-app reading grows by the same amount as before, that traffic was direct all along and has nothing to do with your rules.

Why the numbers do not match iOS system stats

iOS Settings → Cellular shows cellular data usage for the current billing period; it counts every byte on the cellular interface, including connections from all apps, whether or not they go through the tunnel. Shadowrocket's Data page counts bytes that pass through the tunnel, over both Wi-Fi and cellular. The two sample at different points and cover different scopes, so different numbers are inevitable.

Common sources of the difference:

• Scope: system usage covers all network activity on the interface, while the Data page covers only what goes through the tunnel; traffic generated while the connection switch is off is not counted at all.
• Interface: cellular data usage counts only the cellular interface, while the Data page includes Wi-Fi and cellular together — the gap is most obvious on Wi-Fi.
• Reset timing: system usage resets per billing period or when you reset it manually, while the Data page has its own reset, so the two never zero out at the same moment.
• Protocol overhead: bytes inside the tunnel include encryption and encapsulation headers, so the same content usually reads slightly larger on the Data page than the original payload.
• Attribution: the system aggregates interface usage by app, while the Data page groups by server and by app — different dimensions, so rows cannot be lined up one to one.

Troubleshooting order for tracing unusual traffic with the Data page

The sequence below answers the question of whether some app is quietly using traffic. It relies on two preconditions: establish a clean baseline first, then perform only one action, so multiple variables do not mix.

1. Confirm the connection is on

   Check at the top of Home that the connection switch is on. When it is off, traffic does not go through the tunnel and the Data page produces no new readings, which makes the following steps meaningless.

2. Clear the baseline

   Clear both sets of readings on the Data page and note the time you cleared them, so you can compare with system usage.

3. Perform a single action

   Go back to the app you want to observe and do one clear action, such as opening a page and waiting for it to finish loading, while leaving other apps alone.

4. Check by app first

   Switch to the by-app group and see which row grew the most; that row is the source of this action.

5. Then check by server

   Switch to the by-server group and confirm the increase landed on the server you expected; if there is no increase at all, the connection matched DIRECT.

6. Compare against the routing mode

   If the increase shows up on an unexpected server, go back to Home and check the Global Routing mode and Config rules to see whether a rule matched earlier than intended.

Repeat steps 3 to 5 two or three times. If the increase lands on the same row every time, you can be fairly confident about the source; if it varies, the app's background refresh or push notifications may be opening connections at the same time — in that case, send the app to the background and observe another round.

Common questions