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

一、先分清 Data 的两个统计维度

Shadowrocket（小火箭）的 Data 用于查看流量统计。按服务器查看，回答的是“哪个代理服务器承载了流量”；按应用查看，回答的是“哪些应用产生了可归属的流量”。两者是同一批网络活动的不同观察角度，不能直接相加，否则可能重复计算。

进入 Data 后，先确认当前显示的是服务器维度还是应用维度，再读列表里的累计数值。不要把列表第一项默认当成当前连接的服务器，也不要把某个应用没有独立列出理解成它没有联网。系统能否提供应用归属信息、连接是否经过当前统计范围，都会影响呈现结果。

按服务器统计时，同一应用可以先后使用不同服务器；按应用统计时，一个应用也可能同时建立直连与代理连接。因此，“某应用用了多少”与“某服务器用了多少”本来就不要求一一对应。核对时必须固定同一时间窗口，而不是拿两个不同时间读取的总数比较。

二、上行、下行、累计量与速度分别怎么看

上行以本机为观察起点，表示向外发送的数据；下行表示本机接收的数据。打开网页通常以下行为主，但发送搜索词、请求头、确认报文也会产生上行。上传照片通常以上行为主，同时仍会收到服务器确认与页面响应，所以另一方向不一定为零。

文件大小与统计增量不完全相同是正常现象。请求、加密封装、连接建立及重传可能带来额外数据；缓存、压缩和分段请求也会改变本次实际传输量。不同计数位置可能包含不同层次的开销，不能从一个数字推断所有流量都按同一种口径计数。

注意大写 B 与小写 b：B 表示字节，b 表示比特，1 B 等于 8 b。若将 1 MB/s 换算为带宽量级，大约是 8 Mbps，但还要注意 MB 与 MiB 的单位差别及协议开销。Data 的累计字节数本身不是测速结果。

三、按服务器统计：用前后差值定位实际出站

按服务器读数最适合核对“这次请求是否使用了预期的服务器”。在 Home 选中服务器，只代表选择了代理出站对象；是否真的交给它处理，还受 Global Routing 和规则影响。Global Routing 为 Direct 时，请求直连，不应仅因服务器已选中就期待其代理流量持续增加。

1. 在 Home 确认连接状态、当前服务器与 Global Routing。若要检查规则分流，使用 Config 姿态，并到 Config 确认当前启用的配置文件。
2. 进入 Data，记录目标服务器当前的上行、下行和记录时间。暂停其他下载、云同步与流媒体播放，降低背景流量干扰。
3. 只做一个可复现操作，例如在有权限访问的网页下载一个已知大小的文件。不要同时切换服务器或修改规则。
4. 操作完成后回到 Data，等待读数刷新，记录新值，用“操作后减操作前”计算增量。
5. 再检查对应连接的目标、命中规则和实际策略。服务器增量提供旁证，单条连接记录用于确认具体请求。

例如，以下仅是演算示例，不是实测结果：某服务器下行由 120 MB 增至 132 MB，上行由 8 MB 增至 8.4 MB，则本次观察窗口的增量分别为 12 MB 与 0.4 MB。它说明窗口内这个服务器有流量，不自动证明这 12 MB 全部来自刚才打开的页面。

四、按应用统计：区分应用归属与连接策略

按应用查看适合查找后台下载、自动播放或同步任务带来的流量。先找到目标应用，再观察它在同一窗口内的上下行变化。应用有流量并不等于其所有请求都使用代理：一个页面可能同时请求主站、图片域名、视频域名和统计接口，各自可能命中不同规则。

应用名称的展示取决于系统提供的信息。遇到无法单独归属的条目，应保留这个限制，而不是凭目标域名猜测应用身份。浏览器中的多个标签页通常也不适合仅靠应用总量区分；要定位某个页面，应缩小测试窗口，并查看对应目标连接。

• 应用前台没有操作但数字增加：检查后台同步、预加载、自动更新及仍在播放的媒体；先暂停任务，再重复记录增量。
• 打开页面但数字几乎不变：页面可能从缓存读取，或者该流量不在当前可归属范围内。换用一次明确需要网络的新请求核对。
• 应用总量与服务器总量不同：先统一时间范围，再确认是否混有直连请求、其他服务器及无法归属的流量，不要强行逐项对齐。

如果本机没有显示预期的按应用条目，不应据此认定安装异常。先查看当前平台实际提供的统计项目；应用维度不足时，仍可用服务器增量与连接记录完成分流验证。

五、用 Data 核对 Config 规则分流

Data 能显示传输结果的变化，但不负责解释每一条规则为何命中。检查规则时，应先确认 Home → Global Routing 为 Config，再到 Config 核对当前配置。Proxy、Direct 与 Scene 是不同的路由姿态，不能把其他姿态下得到的结果直接当成当前规则文件的验证结论。

完整规则行由规则类型、匹配值与策略组成，FINAL 则直接指定兜底策略。以下是语法示意，不是可直接用于所有网络环境的分流方案；其中 IP-CIDR 使用文档保留地址段，避免误指向真实业务。

DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,PROXY

规则从上到下匹配，命中即停止。DOMAIN-SUFFIX 用于域名后缀匹配，IP-CIDR 用于地址段匹配；IP-CIDR 中的 no-resolve 表示不为这条 IP 匹配主动触发域名解析，不代表整个应用停止 DNS 查询。FINAL 处理前序规则未命中的请求，必须放在需要优先判断的规则之后。

1. 使用自己有权限访问的实际目标，将域名规则放在可能提前命中的宽泛规则之前。
2. 保存并确认正在使用修改后的 Config。关闭旧页面或结束旧连接，再发起新请求，避免旧连接干扰判断。
3. 在连接记录中确认目标及命中策略，然后对照 Data 的服务器增量。若预期 DIRECT，不能仅凭页面可打开就判断代理生效。
4. 完成测试后恢复原配置。若原先使用 Scene，记录其选择条件，避免切回后误把路由变化当成统计故障。

六、流量不一致、断开后增长等常见问题

排查时不必同时修改协议、DNS、规则与服务器。每轮只改一项，并记录测试时间、网络类型、路由姿态、前后读数与连接结果。这样才能把“后台流量”“规则选择”“统计范围”三个问题分开，也便于在后续测试中复现相同条件。