如果你已经连上自己的服务器,却在 Data 页看到按服务器与按应用两组数字对不上,或者发现它与 iOS 设置里的用量统计差了一截,这篇说明按「入口 → 单位 → 两组口径 → 差异原因 → 排查顺序」的顺序讲清每一处读数的含义,并给出一套可复现的定位流程。适合已经完成订阅导入、想用读数判断流量去向的读者。全文以你已有自己的服务商与订阅为前提,文中的服务器名与数字只作排布演示。
Data 页在哪里,两组读数分别统计什么
打开 Shadowrocket,底部标签栏的 Data 就是流量统计页。页面顶部是这一段时间的总量,上行与下行分开显示;下面按分组列出明细,在页面顶部切换分组,即可在「按服务器」与「按应用」两种视角之间切换。连接开关关闭时流量不经过隧道,页面上的数字不会增长,所以看到读数静止,先回 Home 确认顶部的连接开关状态。
两组读数的统计对象并不相同。「按服务器」统计的是归属到某个服务器条目的连接字节数,只有真正经由该服务器转发的连接才会出现在这一列;「按应用」统计的是发起连接的 App,只要连接经过了隧道,无论最终走代理还是直连,都会记到对应条目名下。因此同一段时间里,两组读数的合计通常不相等,差额来自命中 DIRECT 的连接、DNS 查询以及被 REJECT 的连接。
先看哪一组,取决于你要回答的问题:想知道流量落到了哪台服务器,看按服务器;想知道流量由谁发起,看按应用。两组配合使用,才能把「某个 App」与「某台服务器」对应起来。
单位与读法:上行、下行、总量怎么对
每条读数都分上行与下行。上行是设备发出的字节,下行是设备收到的字节,两者不会合并成一个数字,因为它们的排查意义不同:下行异常通常说明有内容在下载或同步,上行异常则更可能与上传、备份、心跳请求有关。
单位按 1024 进制逐级换算,依次是 B、KB、MB、GB,显示时自动选择合适的一级,所以同一行在不同时间可能以 MB 或 GB 出现。读数的口径是隧道内的字节数,包含加密与封装带来的额外开销,通常略大于实际内容体积;一个 1 MB 的文件下载完成,读数显示 1.0x MB 属于正常。
总览 ↑ 15.6 MB ↓ 412.3 MB
按服务器 Server A ↑ 12.4 MB ↓ 386.2 MB
按服务器 Server B ↑ 1.8 MB ↓ 24.9 MB
按应用 Safari ↑ 3.1 MB ↓ 208.7 MB上面的排布只是演示,数字不是实测值。实际列表中每一行还会显示占总量比例,便于快速判断哪一项最大;比例与绝对值一起看,比只看总量更容易发现异常。
按服务器读数:流量落在哪台服务器上
「按服务器」列表里的每一行对应 Home 页服务器列表中的一个条目,名称与 Home 里显示的一致。切换服务器后,新流量记到新条目上,旧条目的历史读数不会自动清零,除非在 Data 页手动把读数清零,或删除对应条目。
这一组读数能直接回答两个问题:当前流量是否落在你预期的服务器上;某台服务器是否在你没有操作的情况下持续产生流量。前者用来核对 Global Routing 与 Config 规则是否按预期工作,后者用来发现配置里被遗忘的条目。
| 读数分组 | 统计对象 | 包含 | 不包含 |
|---|---|---|---|
| 按服务器 | 归属到某个服务器条目的连接 | 经该服务器转发的上行与下行字节 | 命中 DIRECT 的连接、DNS 查询、被 REJECT 的连接 |
| 按应用 | 发起连接的 App | 该 App 经隧道处理的全部连接,含命中 DIRECT 的部分 | 连接开关关闭期间产生的流量 |
如果列表里出现了你不认识的条目,先回 Home 核对服务器列表。条目名与 Home 一致,通常来自你自己导入的配置或手动添加的服务器,不会凭空多出条目。
按应用读数:流量从哪个 App 出去
「按应用」列表把流量归到发起连接的进程上。同一个域名的请求由不同 App 发出时会分别记账,所以它能回答「是谁在跑流量」,这一点系统级统计做不到:系统的用量统计只按网络接口汇总,无法把字节归到具体 App。
Global Routing 的姿态会直接改变两组读数的分布。Config 姿态下,命中规则的连接计入对应服务器,命中 DIRECT 的只出现在按应用列表;Proxy 姿态下,全部连接集中到当前选中的服务器,按服务器列表几乎只剩一行在增长;Direct 姿态下,按服务器读数基本停止增长,按应用读数仍在累计。
配置(Config)
推荐按规则分流:命中规则的连接走对应服务器并计入该服务器,命中 DIRECT 的连接只出现在按应用列表。
适合:日常主力,需要看清哪类流量走了代理
代理(Proxy)
全部连接交给当前选中的服务器,按服务器列表会集中到一行,便于核对总量与隧道开销。
适合:临时全局,核对读数总量
直连(Direct)
全部连接直连,按服务器读数不再增长,按应用读数继续累计,两组数字的差值变得最直观。
适合:验证规则是否误命中、临时对照
排查规则是否误命中时,Direct 姿态是一个干净的对照组:切到 Direct 后再做一次同样的操作,如果按应用读数的增量与之前一致,说明这段流量本来就在直连,与规则无关。
为什么和 iOS 系统统计对不上
iOS 的「设置 → 蜂窝网络」里能看到本计费周期的蜂窝数据用量,它统计的是蜂窝接口上的全部字节,包含所有 App 的连接,不管是否经过隧道;Shadowrocket 的 Data 页统计的是经过隧道的字节,Wi-Fi 与蜂窝都算在内。两者取样位置与覆盖范围都不同,数字不同是必然的。
常见的差异来源有这几类:
- 统计范围:系统用量覆盖接口上的全部网络活动,Data 页只覆盖经过隧道的部分;连接开关关闭期间的流量完全不计入 Data 页。
- 接口范围:蜂窝数据用量只统计蜂窝接口,而 Data 页把 Wi-Fi 与蜂窝一并计入,在 Wi-Fi 环境下两边的差距最明显。
- 清零时间:系统用量按计费周期或手动重置清零,Data 页有自己的清零操作,两者不会同时归零。
- 协议开销:隧道内的字节包含加密与封装头部,同一段内容在 Data 页的读数通常略大于原始载荷。
- 归属方式:系统按 App 汇总接口用量,Data 页按服务器与应用两个维度分组,分组维度不同,无法逐行对齐。
结论:只用 Data 页做相对比较
Data 页的绝对值不必与系统统计对齐,它的价值在于同一段时间内的相对分布。判断异常时,看的是某一行的增量是否与你的操作对得上,而不是总数是否等于系统里的那个数字。
用 Data 页定位异常流量的顺序
下面这套顺序用于回答「某个 App 是不是在偷偷跑流量」。它依赖两个前提:先建立干净的基线,再只做一次操作,避免多个变量混在一起。
确认连接已打开
在 Home 顶部确认连接开关处于打开状态。关闭状态下流量不经过隧道,Data 页不会产生新读数,后续步骤都会失去意义。
清零基线
在 Data 页把两组读数清零,并记下清零的时刻,方便与系统用量对照。
只做一个操作
回到要观察的 App,做一次明确的操作,例如打开一个页面并等它加载完成,其余 App 保持不动。
先看按应用
切到按应用分组,看哪一行的增量最大;这一行就是本次操作的发起者。
再看按服务器
切到按服务器分组,确认增量落在你预期的服务器上;若完全没有增量,说明这次连接命中了 DIRECT。
对照路由姿态
如果增量出现在预期之外的服务器上,回 Home 检查 Global Routing 姿态与 Config 规则,确认是否有规则被提前命中。
把第 3 到第 5 步重复两三次。如果每次的增量都落在同一行,基本可以确认流量来源;如果增量忽大忽小,可能是 App 的后台刷新或推送在同时发起连接,这时把 App 切到后台再观察一轮。
结论:先按量级分类,再决定查什么
两组读数对不上时,先看差额的量级:差额只有几 MB,通常来自 DNS 查询与被 REJECT 的连接;差额达到几百 MB,更可能是某个 App 的流量命中了 DIRECT。先分类再动手,顺序颠倒会把正常现象当成故障。
常见疑问
按服务器加起来比总量少一截,是丢数据了吗?
不是。总量统计隧道内的全部字节,按服务器只统计归属到具体服务器的部分;命中 DIRECT 的连接、DNS 查询与被 REJECT 的连接都只出现在按应用一侧。把按应用的合计与总量对照,通常更接近。
Data 页数字一直是 0,怎么让它动起来?
先回 Home 确认连接开关已打开,再确认 Global Routing 没有停在 Direct;两者都正常,就打开任意网页触发一次连接,读数随后会出现。
换了服务器以后,旧服务器的读数会自动清零吗?
不会。读数按服务器条目分别累计,换服务器只是把新流量记到新条目上;要清零需在 Data 页手动重置,或删除对应条目。
为什么按应用列表里有我不认识的条目?
部分连接由系统服务或后台进程发起,没有可归属的前台应用,会显示为系统或未知条目。这类条目通常量很小;若某一条持续增长,再回 Home 核对服务器列表与 Config 规则。