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

1. Data 页入口与读数：先区分累计量和速率

在 Shadowrocket 主界面进入 Data，查看当前可用的统计分类。按服务器查看时，关注对应服务器的发送、接收与合计读数；按应用查看时，先确认列表是否确实提供应用归属，而不是把目标域名或连接名称当成应用名称。不同设备与界面的可用分类可能不同，本文的按应用说明仅适用于实际显示该分类的情况。

累计流量回答“这个统计窗口内传输了多少数据”，通常以 KB、MB、GB 等单位显示；带有每秒单位的读数回答“当前传输有多快”。两者不能直接比较。页面停在后台后，速率可能归零，但已经累计的字节数不应因此被理解为消失。

• 发送：通常对应设备向外发出的数据，包括请求、上传内容及相关通信数据，并不只等于上传文件的大小。
• 接收：通常对应设备收到的数据，包括网页资源、媒体片段与响应内容。
• 合计：先核对界面的字段定义；不要把合计与发送、接收再次相加，否则会重复计算。

2. 按服务器统计：判断哪条连接实际产生了流量

按服务器视图适合回答“当前测试是否经过预期服务器”。它不是服务商剩余额度页面，也不是手机全部网络用量的汇总。服务器名称只是识别入口；名称相同、订阅更新后重新生成的条目，未必具有完全相同的统计身份。对比前应同时核对服务器地址、端口与所属分组。

Home 中选中了某个服务器，不代表所有连接都必须经过它。Global Routing 处于 Config 时，连接由当前配置中的规则和策略决定；规则可能选择其他策略，也可能选择 DIRECT。因此，选中服务器的计数不增长，首先要检查目标连接的实际出站，不能立即认定统计故障。

3. 按应用统计：应用归属不等于整台设备的用量账单

按应用视图用于观察被识别到的应用流量分布，但不应被当作系统级应用用量清单。应用归属取决于客户端与系统提供的可见信息；某些连接可能无法得到明确的应用名称，也可能显示为未识别项。缺少某个应用的名称，不等于该应用没有联网。

同一个应用可能同时访问登录、图片、视频与统计等多个域名，其中一部分走代理，另一部分走 DIRECT。反过来，同一域名也可能被多个应用调用。因此，“域名列表”“按应用列表”和“按服务器列表”是不同维度，不能只靠一条域名记录推断整个应用的出站。

1. 关闭不参与测试的前台应用，暂停明显的后台下载，记录测试开始时间。
2. 只打开一个目标应用，执行一次明确操作，例如刷新一页内容；避免同时播放媒体、同步相册等。
3. 返回 Data，查看该应用或未识别项是否出现新增流量，再对照服务器增量。
4. 如果界面没有按应用入口，改用连接记录中的目标地址、时间与出站进行核对，不用域名名称冒充应用归属。

4. 统计周期与清零：先保存基线，再执行重置

不要默认 Data 每月自动清零，也不要把 VPN 的一次连接时长当作所有统计的起点。界面若标注会话、日期范围或累计周期，应以该标注为准；若没有明确起点，就从现在建立一组可追溯的基线。断开连接、退出应用、更新订阅，都不应被当作可靠的清零方法。

需要清零时，在 Data 页查找 Reset 或对应的统计重置操作；若入口收在页面操作菜单中，先展开菜单，再核对确认提示的作用范围。界面没有提供该操作时，不必删除配置或重装应用，使用前后读数相减即可完成本次测试。不要把删除服务器、清除连接记录与重置统计混为同一操作。

1. 保存旧读数：记下日期、时间、分类、服务器标识以及发送和接收数值；需要留存历史时，先在本地保存记录。
2. 暂停测试流量：停止下载或播放。检查 Settings → On Demand 的触发条件，避免预期之外的自动连接干扰观察；测试结束后恢复原设置。
3. 确认重置范围：阅读确认提示，区分当前分类、单个条目与全部统计。仅按实际提示执行，不假定所有分类会一起归零。
4. 立即复查：回到同一分类查看结果，记录新的起点。若马上出现少量读数，先检查后台通信，而不是反复重置。

测试窗口：开始读数至结束读数
发送增量 = 结束发送值 - 开始发送值
接收增量 = 结束接收值 - 开始接收值
总增量 = 发送增量 + 接收增量

计算前应统一单位。以下仅为演算示例，不是实测结果：开始接收为 120 MB，结束接收为 128 MB，则该窗口的接收增量为 8 MB。如果期间重置过统计，或条目被替换后读数变小，这一组数据不能直接相减，应重新记录基线。

5. 用 Data 验证分流：规则记录与流量增量必须对应

流量增长只能证明发生了传输，不能单独证明命中了哪条规则。完整检查需要同时确认 Global Routing、当前配置、目标连接命中的规则及实际出站。Global Routing 中的 Proxy、Direct、Config、Scene 不是统计分类；验证配置规则时应选 Config，使用 Scene 时则先核对场景的实际设置。

1. 进入 Home → Global Routing，选择 Config；再到 Config 确认正在使用的配置文件，避免只编辑了未启用的文件。
2. 记录 Data 中预期服务器的当前读数，并结束目标应用已有的测试连接。规则修改通常需要新连接才能得到清晰的验证结果。
3. 对一个已知目标发起请求，打开连接记录核对目标域名或 IP、匹配规则与实际出站。连接记录入口以当前界面提供的位置为准。
4. 返回 Data 比较同一服务器的增量；同时观察是否有其他服务器增长，并排除后台流量。
5. 如需对照测试，每次只改一个条件，例如只改变目标规则，不同时更换服务器、网络与 DNS 设置。

下面是规则结构示意，使用保留示例域名，不代表可用服务。只有当前配置确实存在名为 PROXY 的可用策略时，才能按此策略名引用；已有配置使用其他策略名时应保持原有命名。不要为了做统计测试，直接覆盖整个配置。

DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

在此示意中，匹配 example.com 及其子域名的连接交给 PROXY，其余连接由 FINAL 交给 DIRECT。实际配置中的 DOMAIN-SUFFIX、GEOIP、IP-CIDR 等规则会按顺序参与匹配；较早命中的规则可能使后面的规则不再被执行。应查看具体连接记录，而不是只确认文件里出现了某个关键字。

6. Data 与服务商用量不同：先对齐口径再比较

服务商账单可能采用不同的计费周期、上下行算法、倍率与刷新间隔；Data 则反映客户端可统计到的本地数据。协议封装、统计位置和单位换算也可能产生差异。即使两边都显示 GB，也不能直接推断它们有完全相同的字节换算与计费定义。

• 对齐时间：用同一开始与结束时间比较，不把 Data 历史累计量与服务商本月用量直接相减。
• 对齐设备：服务商账户可能同时汇总其他设备的使用，当前设备的 Data 不负责显示那些流量。
• 对齐方向：确认服务商计算接收、发送还是两者合计，是否存在明确标注的计费倍率。
• 对齐刷新：本地读数增加后，服务商页面可能尚未结算；等待其说明的刷新周期再比较。

订阅条目旁显示的套餐额度或到期信息，如果由已有服务商返回，属于服务商提供的数据，不是 Data 的本地计数。更新订阅不能保证重置 Data，重置 Data 也不会改变服务商已记录的用量。两类信息应分别留存、分别判断。

7. 常见问题：零读数、后台增长与清零后的影响