Data
The screen has four independent signals.
The switch says whether the tunnel is up. Policy says whether rules are asked after traffic is in the tunnel. Data says which side already-happened bytes took. The list probe only says whether this hop probes right now. Trust one group at a time.
01
What each is answering
- Switch
- Whether the extension is running. Sitting on, with a VPN icon: the tunnel is up. Flicker, snap-back: handshake never established, or there is no usable VPN configuration on the system. Details in Tunnel.
- Policy
- Config is what runs rules. Proxy ignores rules; outbound enters the current record. Direct ignores rules; outbound takes the system path. The VPN icon can be on under Direct, so the icon cannot stand for “it used the node.”
- Data
- Two counters, Direct and Proxy, count bytes that already happened. This is an on-device count, not plan remaining, and it cannot see how much quota is left in any third-party account. A reset starts from zero and does not affect remote quota.
- Probe
- The millisecond number on the list is probe round-trip. A timeout only means this hop does not probe now. A successful probe does not prove a page, API, or video works at the app layer; a failed probe does not automatically mean “the rule is wrong.”
The four signals can combine in any way, so looking at one group alone misleads. Switch on + policy Direct + Data rising only on Direct: working as designed, just not using the node. Switch on + policy Proxy + Data still: the request may not have entered this record, or the far end sent no bytes back. Switch on + small probe + page fails: the tunnel and this hop are up; failure is higher, at the app layer or in rules.
02
Visit once, see which counter rises
Turn the switch on, visit a host you believe should enter the current record, then look at Data. Do not open ten pages and then look at totals — Direct and Proxy may both have moved, with no way to map them to one visit.
Proxy rose: bytes entered this record. If the page still fails, the problem is usually the far end, DNS, or the app refusing VPN — not “it did not use the node.” Editing rules then is repairing a path already proven to use the record.
Only Direct rose: the request stayed on the system path. If you expected the record, see whether policy is Direct, or whether under Config a rule wrote DIRECT / REJECT first. See Rules.
Both barely move: the request may never have entered the tunnel (switch, VPN configuration, another VPN holding the slot), or there is no outbound at all (the app is still local, the captive page is unfinished, Airplane Mode). Look at the switch, then System.
A REJECT hit usually does not push the counters the way a successful load does. The app errors, Data is quiet, and it looks like “the node has no traffic.” Switch policy to Proxy once to separate the two.
The two counters only split left and right; they do not say “which record.” Proxy numbers from before you changed the highlight remain; they are not zeroed per row. To attach a count to a row, reset first, then fix that row and make one visit.
03
Fix one record, change only policy
During isolation do not change the highlighted row, do not edit the rule file at the same time, and do not refresh a container. After you pick one row in the list, only move Config / Proxy / Direct.
-
Direct
Local visits and the captive login page should work. If there is already no network here, fix Wi-Fi / cellular / the captive page; it is not the record. Data should rise mainly on Direct.
-
Proxy
A host expected to use the record should open here: the tunnel and this record work at the app layer. If the same host later fails under Config, look at rules. If it cannot open here either: the problem is the record or the far end — do not start with FINAL.
-
Config
Only after Proxy has proven the record works, adjust rules. Change one condition at a time, and use Data to see which side the count sits on. If after the edit only Direct still rises, the new line was not hit, or a line above intercepted it.
The point of this order is attribution. Direct fails, fix the local network. Proxy fails, fix the record. Config fails while Proxy works, fix rules. Doing all three at once lets every on-screen change be explained by the other two variables — which is no explanation.
04
A small probe number, and the page can still fail to open
The list probe usually only walks this hop’s handshake or an ICMP / TCP probe; it does not load the site you are using. So:
- Probe succeeds, page fails: this hop probes now; failure is DNS, rules, the far-end site, or that App refusing the tunnel.
- Probe fails, some pages still open: those pages may have taken DIRECT and never used this record. Look at Data, not at milliseconds.
- Every row’s probe fails: look at the local network and system time before you suspect “every record expired together.” The former is common; the latter is not.
Probe results are momentary. After a Wi-Fi / cellular handoff, the number from a moment ago is void. Do not treat 28 ms from ten minutes ago as proof it still works now.
05
Cases that are not about one record
If system time is not set automatically, TLS fails in batches. The switch looks wrong on every record, and probes fail with it. Turn on Set Automatically before you talk about records.
When the destination is IPv6 and rules only list IPv4 IP-CIDR, the request falls to FINAL and looks like a rule that “sometimes works.” See IP-CIDR6 on the Rules page, and DNS.
Another VPN is connected: the system may not hand traffic to this extension. A lit switch does not mean bytes entered Shadowrocket. Data still, another VPN app shows connected — handle coexistence first; see System and Tunnel.
Until Captive Portal (hotel, airport, campus login) is finished, the device itself has no network. Direct should be able to open the login page first. Flipping the switch, refreshing a container, or editing rules then is work on a device with no outbound.