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

本文速览

Data 适合观察流量变化，不宜单独用来认定某条规则命中或核对线路账单。本文面向已经完成连接配置的 iPhone、iPad 用户：先区分上传、下载与归类口径，再用同一时间窗口的增量测试，结合 Global Routing、Config 和连接记录判断流量去向。

一、先区分累计流量与实时速度

Shadowrocket（小火箭）的 Data 读数要连同单位一起看。上传是设备向外发送的数据，下载是设备接收的数据；打开网页也会产生上传，因为浏览器需要发送请求、连接协商信息等。下载较多并不意味着上传应当为零，上传增加也不等于设备正在上传文件。

表示容量的 KB、MB、GB 与带有时间分母的 KB/s、MB/s 不是同一概念。前者用于描述一定范围内累计的数据量，后者表示传输速率。累计值很大只能说明此前传输较多，不能证明当前速度快；页面停止加载后，累计值也不会因为速度下降而自动减少。

2 个方向

上传：设备发出；下载：设备接收

60 秒

本文建议的单轮固定观察窗口

2 次读数

结束值减起始值，得到本轮增量

上面的 60 秒是测试方法，不是 Data 的固定刷新周期。实际统计是否保留、何时刷新，以及哪些分组可见，应以设备上当前页面为准。开始比较前先记录时间、单位和分组，避免拿昨天的累计值与今天的一次网页请求作比较。

二、按服务器与按应用：两种归类不能直接相加

按服务器查看时，重点是某个服务器条目在观察期间是否新增上传和下载。它回答的是“这个出站相关的统计有没有变化”，而不是“是哪一个前台应用独占了全部流量”。多个应用可能使用同一个服务器，策略切换也可能让同一应用的不同连接使用不同出站。

按应用归类时，重点是页面能够识别并归入相应条目的流量。Apple 平台上的来源识别存在边界，不能把这一视图理解为系统里所有应用的完整审计。系统服务、后台任务或无法明确归属的连接，可能无法以预期的应用名称出现；实际显示的分类比名称猜测更可靠。

观察维度	适合回答	不能单独推出
按服务器	哪个服务器条目在本轮增加了流量	所有增长都由某个前台应用产生
按应用	可识别的来源条目是否有新增传输	该应用全部请求都命中了同一规则
上传与下载	发送与接收分别增加多少	与服务商计费流量逐字节一致

判断方法：分别比较增量，不把两种分组求和

先在同一分组内比较测试前后读数，再到另一分组核对变化方向。服务器与应用是观察流量的不同维度，把两个视图的数值相加可能重复计算，不能得到更准确的总量。

三、统计口径与清零：先留记录，再建立基线

Data、系统网络用量和服务商账单可能在统计起止时间、覆盖范围、协议封装及单位换算上不同。即使观察同一次下载，也不应要求三处数字完全相等。尤其不要把客户端显示的下载量直接当作订阅剩余额度；额度与计费周期应回到你的服务商提供的信息核对。

清零是为了缩短观察窗口，不是修复连接的必要步骤。断开再连接、退出应用或更新订阅，也不能被当作“统计一定归零”的依据。若当前 Data 页面提供清零操作，执行前先确认它作用于单个条目还是整个统计范围，并保留所需记录；不要凭图标位置猜测操作范围。

先记录：保存当前服务器名称、上传与下载读数、记录时间，以及本轮使用的 Global Routing 姿态。
再选基线：需要保留历史时不必清零，直接把当前数值作为起始值；需要全新窗口时，再使用页面实际提供的清零控件。
核对结果：清零后重新查看目标分组。存在后台连接时，读数可能很快再次增长，不应要求它长时间保持为零。
统一条件：下一轮继续使用相同网络、相同测试资源和相同时长。切换 Wi-Fi 与蜂窝网络后，应重新记录一轮。

四、判断规则分流：先确认 Global Routing

Data 反映流量变化，规则决定请求如何选路，两者不能互相替代。在 Home 查看 Global Routing：使用 Config 时才应按当前配置中的规则检查匹配结果；使用 Proxy 或 Direct 时，不要仍按 Config 内某条域名规则解释现象。若使用 Scene，应先核对当前场景及其生效设置，再安排测试。

确认路由姿态核对当前配置建立统计基线发起新请求对照连接记录

下面是规则语法示意，不是供整段覆盖现有配置的方案。示例中的 PROXY 必须对应当前配置实际可用的策略。example.com 是说明用途的域名，不能据此验证你实际业务的分流结果。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

DOMAIN-SUFFIX：按域名后缀匹配；同一个页面的图片、视频和接口可能来自其他域名。
IP-CIDR：按目标 IP 网段匹配；示例中的 no-resolve 表示不为这一条 IP 规则主动进行域名解析。
GEOIP：依据 IP 地理归属匹配，不能用网站显示的语言来推断是否命中。
FINAL：作为前面规则未匹配时的兜底；应同时检查它之前是否已有规则先行匹配。

在 Config 确认正在使用的配置及规则顺序后，再发起新的连接。修改规则前已建立的长连接可能继续沿用原有出站，因此只刷新 Data 并不能保证请求重新匹配。应停止原测试任务，重新发起请求，并在可用的连接记录中核对目标域名或 IP、匹配规则与出站策略。

五、一次 60 秒对照测试：用增量缩小范围

测试前暂停其他大流量任务，选择一个你有权访问、能够重复请求的资源。保持 Home 中的连接与服务器选择不变，记录 Data 的起始值，再持续观察 60 秒。不要同时更新订阅、更换协议或修改规则，否则即便数字发生变化，也难以确定是哪一个因素造成。

示例读数	测试前	测试后	本轮增量
服务器下载	120 MB	132 MB	12 MB
服务器上传	8 MB	9 MB	1 MB

表中数字仅用于演示计算，不是性能实测。下载增量 12 MB 除以 60 秒，得到这一窗口约 0.2 MB/s 的平均值；它包含等待时间，不等于下载过程中的峰值。若页面显示值经过舍入，差值也只是近似值，不适合据此比较很小的请求。

下一步：让统计变化与具体连接互相印证

目标服务器增长而测试资源成功加载，只能支持“该服务器本轮有传输”。要确认指定域名分流正确，还要核对该请求的规则与出站；若数字未变，先排除缓存和旧连接，再考虑规则或配置问题。

若需要比较 Direct 与代理路径，应分成独立轮次，每次重新建立基线，只改变一个条件。使用浏览器缓存命中的页面做对照可能几乎不产生新下载；可选用能确认重新请求的自有测试资源，但不要以无意义的大量传输消耗套餐。

六、常见读数疑问与检查顺序

没有打开网页，为什么 Data 还在增加？

先暂停同步、媒体播放等已知任务，再观察一个固定窗口。后台请求、连接保活及系统服务都可能产生流量；如果在 Settings → On Demand 配置了按需连接，还应核对当前是否由相应条件触发连接。不能仅凭少量增长认定存在异常传输。

网页能打开，但所选服务器的数字不动，是分流失败吗？

先到 Home 核对 Global Routing 与服务器选择，再到 Config 检查生效配置。资源可能来自缓存、通过 Direct 访问，或使用了其他策略选中的服务器。发起一次新请求并核对连接记录，比反复切换开关更有判断价值。

按应用列表里没有找到正在使用的应用，怎么办？

不要把缺少应用名称理解为没有联网。先看同一窗口的整体变化与服务器增量，再结合该请求的目标和时间确认连接。对无法准确归属的条目保留不确定性，不要强行把所有未识别流量分配给某个应用。

订阅更新后流量读数不同，需要重新清零吗？

先检查服务器条目、策略引用及当前选择是否发生变化。订阅更新与统计清零是不同操作；保留旧记录后重新设定起始值即可继续测试。若条目被替换，不要仅凭相同显示名称就把前后数值当作同一条连续记录。

排查结束后恢复原先需要的路由设置，保留“时间、网络、配置、服务器、起止值、目标请求”这六项记录。Data 用于发现变化，连接记录用于解释去向，服务商信息用于核对额度；把三者分工明确，比反复清零更容易复现问题。更多基础操作见Global Routing 使用说明，域名解析问题可继续查看DNS 排查。