Shadowrocket Data 页流量统计怎么看:按服务器与按应用的读数含义

本文速览

Shadowrocket（小火箭）的 Data 页用于观察客户端记录的流量，不是服务商的套餐账单。已有服务器配置的用户，可以先区分上行、下行与累计值，再分别查看服务器归属和应用活动，最后用一次受控访问的前后差值检查分流。本文同时说明统计起点、后台流量与读数不一致时的排查顺序。

一、先分清流量大小与连接速度

Data 页中的流量读数表示已经传输了多少数据。上行是设备向外发送的数据，下行是设备从外部接收的数据。打开网页时，发送请求会产生上行，接收文字、图片和视频会产生下行；上传照片时，上行通常更明显。即使主要在下载，上行也不一定为零，因为连接建立、请求和确认等过程仍需要发送数据。

先看数值后面的单位，再看数值大小。KB、MB、GB 表示数据量；带有每秒含义的单位才表示速率。累计下行较大，只能说明观察范围内接收的数据较多，不能据此判断当前速度，也不能用它代替 Connectivity Test 的连接检查结果。

2 个方向

上行：设备发送；下行：设备接收

2 种视角

按服务器归属与按应用活动观察

2 次记录

访问前、访问后各记一次，计算差值

流量统计也不等于访问成功。一个失败请求可能已经发出了数据，随后因解析、握手或远端响应问题结束；反过来，命中本地缓存的页面可能正常显示，却只产生少量新流量。应把 Data 读数与实际访问结果一起判断。

二、按服务器与按应用，分别回答什么问题

按服务器查看，重点是某个服务器条目在统计范围内承载了多少流量。按应用查看，重点是哪些应用活动产生了可归属的流量。这是同一类网络活动的不同观察角度，不是两份可以直接相加的套餐用量。

观察视角	可以判断	不能单独证明
按服务器	某个服务器条目的累计量或本次观察增量	所有应用都使用了该服务器
按应用	可识别应用的流量分布及增长情况	该应用的每个请求都使用同一策略
上行与下行	发送和接收的数据量差异	实时带宽、延迟或剩余套餐额度

应用归属还受系统提供的信息和当前统计能力限制。出现无法明确归属的记录时，不要直接认定是未知应用或异常程序。一个应用可能访问多个域名，也可能同时存在直连和代理请求，因此“应用有流量”与“某个服务器有流量”并不是一一对应关系。

结论：用同一时间窗核对两种视角

先记录服务器和目标应用的当前读数，再只操作一个应用。对照同一段时间内的增量，不要拿服务器的历史累计值去比较应用刚出现的少量活动。

三、统计从何时开始计，为什么不能当套餐账单

统计的前提是相关流量经过 Shadowrocket 的处理并被记录。安装应用的时间、购买时间、导入订阅的时间，都不能直接作为 Data 当前数值的起点。也不能把所有字段统一理解成“自本次打开界面以来”：当前连接数据与保留的累计记录需要分别看待。

判断统计起点时，优先查看当前页面是否明确给出时间范围、连接时长或重置状态。没有明确时间标识，就不要将数值称为“今日用量”或“本月用量”。连接断开后是否保留某项读数，应以该字段实际变化为准；不能假设每次重连都会清空全部历史。

需要测一段访问：在访问前记录数值和时间，访问后再次记录，用差值建立自己的观察区间。
切换过服务器：分别保存切换前后的记录，不把旧服务器的累计值当成当前服务器本次消耗。
执行过清理或重置：将操作时刻记为新的比较边界，不再与重置前的累计值直接相减。
需要查剩余额度：前往你的服务商提供的用量页面核对，计费周期和扣量规则由服务商说明。

客户端与服务商可能在不同位置计数。协议封装、统计刷新间隔、流量倍率及计费周期都可能影响最终显示，因此两边不必完全一致。设备蜂窝数据统计又是另一种口径，可能包含 Shadowrocket 未处理的系统活动。三个页面的数字不能在未核对范围时直接互相替代。

四、按五步建立一次可复查的流量观察

下面的操作不要求修改服务器参数，也不要求重新导入订阅。先使用你已有的配置；如尚未具备订阅，应从你的服务商处获取。测试时只选择一个明确的访问动作，例如在 Safari 打开一个未缓存的页面，避免同时播放视频、更新应用或同步大量照片。

确认连接

进入 Home，在 SERVER 列表确认当前选中的服务器，打开顶部连接开关，再运行 Connectivity Test。测试结果只作为连通性线索，还需实际打开目标页面。
核对姿态

进入 Home → Global Routing，记下当前是 Config、Proxy、Direct 还是 Scene。使用 Config 时，再到 Config 核对当前启用的配置，不在测试中途切换。
记录基线

打开 Data，分别记下目标服务器和目标应用当前的上行、下行数值及时间。暂时停止其他前台下载，并留意后台同步仍可能继续。
执行访问

回到 Safari 完成一次页面访问，记录开始和结束时间。不要同时切换 Wi-Fi、蜂窝网络或服务器，否则难以解释流量归属变化。
比较增量

回到 Data 等待读数刷新，再记录相同字段。用后值减前值，并结合访问是否成功、当前路由姿态和请求记录一起判断。

以下只是差值计算示例，不是实测结果或性能承诺。单位应保持一致；如果界面显示经过四舍五入，小流量访问可能看不出明显变化，可延长观察时间，而不是立即判定记录失效。

字段	访问前	访问后	本段增量
服务器下行	100 MB	120 MB	20 MB
服务器上行	10 MB	11 MB	1 MB

五、结合 Global Routing 判断分流是否符合预期

Data 提供结果线索，Global Routing 和当前配置决定如何处理流量。发现服务器读数增长之前，应先确认当前姿态。尤其不要在 Proxy 下观察完流量，就据此认定 Config 中某条规则已经命中。

Config

Proxy

使纳入处理范围的流量使用代理路径，适合作为连通性对照。它不能证明 Config 中的某条 DOMAIN-SUFFIX 或 IP-CIDR 规则有效。

适合：临时区分服务器问题与规则问题

Direct

使用直连路径。服务器代理流量不增长可能与该姿态一致，不能仅凭服务器读数为零判断连接故障。

适合：对照目标在直连路径下的访问情况

如果使用 Scene，应先核对当前场景对应的设置及生效条件，不要把 Scene 当成固定等同于 Proxy 或 Direct 的第四种路径。测试前后保持场景一致，才能让差值具有比较意义。

在 Config 中，规则顺序同样重要。DOMAIN-SUFFIX 按域名后缀匹配，GEOIP 按 IP 地理数据库匹配，IP-CIDR 按地址段匹配，FINAL 承接前面未匹配的请求。最终去向由命中规则指定的策略决定，而不是由应用名称决定。

[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY

这段仅用于解释规则语法：example.com 及其子域名匹配 DIRECT，其余由 FINAL 指向 PROXY。测试前必须确认配置支持所引用的策略；不要为观察流量而直接覆盖现有配置。完整网页还可能请求其他域名的资源，因此即使主域名直连，也可能看到部分代理流量。

结论：流量增长只能证明有数据经过

要确认某个目标是否命中预期规则，应在同一次访问中对照请求记录里的目标、命中规则和最终策略，再用 Data 增量辅助验证，不以整页总量替代逐请求判断。

六、读数异常时，按现象排查

先保留现象，再改动设置。记录观察时间、网络类型、Global Routing 姿态和访问目标，通常比反复重连更有助于定位原因。每次只改变一个条件，完成一次访问后重新记录 Data，避免把多个改动的结果混在一起。

网页能打开，服务器流量怎么没增加？

先查 Home → Global Routing 是否为 Direct，再检查 Config 中目标是否命中 DIRECT。随后用未缓存内容重试并等待 Data 刷新。缓存命中、单位取整或观察了错误的服务器条目，都可能让增量不明显。

没有操作，流量为什么还在涨？

先暂停云同步、媒体播放和应用更新，再观察应用视角的增量。接着检查 Settings → On Demand 是否已启用及其条件，确认是否存在自动触发连接的情况；回到 Home 核对实际连接状态，不要只凭先前关过开关判断。

某个应用的数值与服务器数值对不上？

重新统一观察起止时间，并停止其他应用活动。该应用可能同时产生直连与代理请求，服务器也可能承载其他应用的流量；应用识别范围和显示取整同样会影响对照，不应强求两个累计值相等。

服务商显示的用量比 Data 多怎么办？

先对齐套餐计费周期，再核对你的服务商说明的倍率、刷新延迟及同一账户其他设备的使用情况。Data 用于客户端观察，剩余额度以服务商账单为依据；提交排查材料时不要附带订阅链接或认证信息。

最后，把一次完整检查收束为四项记录：当前连接、当前姿态、访问前后差值、目标请求的最终策略。若 Connectivity Test 与实际访问均失败，应优先处理网络或服务器连通性；若访问正常但路径与预期不符，再回到 Config 检查规则顺序。Data 是验证链条中的一环，不是独立的故障结论。