本文适合已经有自己的服务商参数、希望核对流量去向的用户。先区分累计字节与实时速率，再分别按服务器和应用活动观察增量，最后用同一时间窗口对照服务商后台。Data 是客户端观察记录，不是套餐余额，也不能直接当作设备全部网络用量。
一、Data 的上传、下载与累计值分别表示什么
Shadowrocket（小火箭）的 Data 用于查看客户端记录到的流量。上传和下载以本机方向为参照：本机向外发送是上传，外部向本机返回是下载。打开网页也会上传请求、确认信息和其他数据，因此“只是看网页”不代表上传必须为零。上传照片时，也会收到服务器的响应。
读数必须连同单位一起看。MB、GB 表示数据量；KB/s、MB/s 表示单位时间的数据传输速率。连接开关处于开启状态，并不意味着每秒都有业务数据传输；短时速率降到零，也不能单独证明连接异常。具体字段、分组和统计保留方式以设备上实际界面为准。
| 读数类型 | 可说明什么 | 不能直接推断什么 |
|---|---|---|
| Upload / 上传 | 本机向外发送的数据量 | 用户主动上传文件的净大小 |
| Download / 下载 | 外部向本机返回的数据量 | 最终保存到相册或文件中的大小 |
| Total / 合计 | 相应范围内的上传与下载合计 | 服务商套餐剩余额度 |
| 带 /s 的数值 | 当前采样窗口内的传输速率 | 本月累计消耗 |
不要默认每个读数都从本月一日开始累计，也不要默认断开后一定清零。先确认当前显示的是连接期间数据还是保留的累计记录；如果界面没有明确标注起点，使用测试前后差值，而不是凭总数猜测统计周期。
二、按服务器看：记录的是连接去向，不是账户总账
按服务器分组适合回答“这段时间哪一个服务器条目产生了数据”。它与服务商账户不是同一层级：同一账户可能在多台设备上使用，也可能对应多个服务器地址；本机条目的记录只代表客户端能够观察和归类的部分。名称相同的条目也不一定指向相同地址，核对时应同时看地址、端口和协议。
在 Home → Global Routing 中确认当前姿态。Proxy 用于代理处理，Direct 用于直连处理，Config 按当前配置规则分流；使用 Scene 时还应核对当前场景实际采用的处理方式。只有实际走相应代理出站的流量，才适合与该服务器的用量比较，不能把设备所有网络活动都归入当前选中的服务器。
- 在 Home 记录当前选中的服务器，并核对其地址、端口与协议，避免只记显示名称。
- 记录 Data 中该服务器的上传、下载起始读数；测试期间保持同一出站，不切换服务器或策略。
- 完成一次明确操作后，再记录结束读数，以结束值减去起始值计算增量。
- 如果服务器有数据而某网页未走该服务器，检查其他后台请求；如果网页可用但服务器没有增量，先检查是否命中 Direct。
例如，Config 中的 DOMAIN-SUFFIX,example.com,DIRECT 会让匹配该后缀的请求走 Direct，而 FINAL,PROXY 处理未命中前序规则的请求。这里的域名仅为语法示例，不要求添加到实际配置。不要为了让统计数字增加而随意删除已有规则。
三、按应用看：先确认归属依据，再判断谁在用流量
“按应用”关注的是业务来源，“按服务器”关注的是出站去向，两者是同一批活动的不同观察角度，不能把两组总数相加。还要注意平台限制：iPhone/iPad 的系统网络扩展并不保证为每条连接提供可直接对应到应用名称的身份信息，不能把域名或连接分类自动理解为精确的应用账单。
如果当前 Data 界面提供应用相关分组，先看清分组标签和可用信息；如果只有服务器或连接记录，就用单应用测试辅助判断，不要寻找一个被假定存在的固定菜单。一个应用可能访问多个域名，多个应用也可能共用同一内容分发域名，单凭域名名称无法可靠判定归属。
按服务器核对
- 观察对象
- 实际使用的服务器条目
- 识别依据
- 地址、端口、协议和出站选择
- 测试条件
- 固定服务器与 Global Routing
- 适合问题
- 哪个出站产生了流量
同一应用的请求可能经不同规则分到不同出站。
按应用活动核对
- 观察对象
- 一次明确的前台操作
- 识别依据
- 操作时间、连接记录与增量
- 测试条件
- 暂停其他下载与后台同步
- 适合问题
- 哪类操作引起了流量增长
无法确认应用身份的流量应保留为未归类，不强行分配。
实际核对时，先停止视频播放、云端同步和其他下载，记录一分钟空闲增量，再只打开一个应用执行一次操作。第二次重复相同操作时，如果增量明显降低，通常应先检查本地缓存，而不是认定统计失灵。应用预加载和后台任务仍可能混入测试，所以这种方法用于定位来源，不用于精确结算。
四、用一组前后读数计算本次消耗
下面是一组计算示例，不是产品实测结果。假定测试前后界面采用同一种 MB 计量单位，期间没有清空记录、切换服务器或改变统计范围。用差值可以排除之前累计数据的干扰；测试时应同时保存时间，便于与后台刷新后的数据对齐。
| 项目 | 10:00 起始值 | 10:05 结束值 | 本次增量 |
|---|---|---|---|
| 上传 | 12 MB | 15 MB | 3 MB |
| 下载 | 240 MB | 300 MB | 60 MB |
| 上传与下载合计 | 252 MB | 315 MB | 63 MB |
本次合计为 (15 - 12) + (300 - 240) = 63 MB，不能把结束时的 315 MB 当成本次消耗。若只按该显示单位计算，五分钟平均下载速率为 60 ÷ 300 = 0.2 MB/s；它是整个观察窗口的平均值，不是传输过程中的峰值，也不能直接代表线路最高速度。
判断：对账先取增量，再统一单位
先把客户端与后台都换成同一时间段的差值，再核对单位和计费规则。仅比较两边累计总数，即使数值相近，也不能证明统计范围一致。
单位换算也会造成差异。十进制 1 GB 是 1,000,000,000 字节，二进制 1 GiB 是 1,073,741,824 字节；同一批字节换成不同单位后，显示数值不同。若页面只写 GB 而没有定义，不要擅自认定换算方式，应查看对应说明或向已有服务商确认。
五、为什么 Data 与服务商后台用量不一致
客户端和服务商可能在网络链路的不同位置计数。业务数据经过协议封装后，还会包含连接建立、加密记录等额外开销；重传是否计入、计入哪一层，也取决于统计点。不能用固定百分比解释所有差额，更不能直接把差额等同于异常消耗。
- 计费方向不同：后台可能合计上传和下载，也可能采用其他约定。先确认说明，不能仅用客户端的 Download 去比后台合计。
- 统计范围不同：后台可能汇总账户在其他设备上的使用；本机 Data 不包含那些设备的本地记录。
- 时间窗口不同：后台可能延迟入账，账期起点、时区和刷新时间也可能不同。保存两边读数对应的时间。
- 倍率与扣费规则不同：若已有服务的条款明确使用倍率，后台扣减值可能不是原始传输字节。按已公布规则核对，不自行猜测。
- 本地记录起点不同：清空统计、配置调整或记录保留范围变化，都会使本机累计值无法与整个账期直接比较。
- 流量路径不同：Direct 流量不经过该代理服务器；系统其他连接的观察范围也不能与客户端统计简单画等号。
例如，本次客户端上传增加 3 MB、下载增加 60 MB，而后台稍后增加 63 MB，至少在该观察窗口内符合双向合计的计算方式。如果后台显示 126 MB，应先查是否存在明确的 2 倍计费规则或其他设备活动；这个算例只是检查顺序，不能据此断言实际服务采用某种计费方式。
六、读数异常时，按什么顺序检查
先排除统计范围和测试条件，再检查连接与配置。更新订阅可能改变服务器条目或参数，因此不要在同一轮对账中同时更新订阅、切换协议和调整规则。每轮只改变一个条件，才能判断读数变化与哪项操作有关。
“没打开应用，流量为什么还在增加？”
先暂停云端同步、媒体播放和自动下载，记录一分钟空闲增量。再检查 Settings → On Demand 的连接触发条件：它可以按条件建立连接，但不代表每一笔流量都由 On Demand 本身产生。后台任务、通知和已有连接仍可能传输数据。
“网页能打开，服务器统计却没有增加？”
先在 Home → Global Routing 确认姿态，再核对 Config 中该请求匹配的规则与出站。命中 Direct、浏览器直接使用本地缓存，或者查看了另一个服务器条目，都可能使目标服务器读数不增长。
“Data 的数字突然变小，是返还流量了吗？”
先确认是否切换了分组、服务器或统计范围，并回顾是否清空过记录。客户端显示值变小不能说明服务商额度发生变化；套餐余额需要在已有服务商后台单独核对。
“按应用相加，为什么对不上服务器总数？”
先确认两边时间窗口相同，再检查未归类流量、Direct 路径与后台活动。应用身份不能可靠确定时，不要把差额强行记到某个应用；改用单应用操作前后增量，定位最明显的增长来源。
- 固定一个服务器和一种 Global Routing 姿态，保存起始读数与时间。
- 暂停其他明显网络活动，完成一次可重复的前台操作。
- 保存结束读数，分别计算上传、下载和合计增量。
- 等待服务商后台完成本轮入账，核对同时间段、同账户范围和同计量单位。
- 仍有差异时，带着脱敏记录向已有服务商询问计费方向、倍率和统计刷新周期。
Data 最适合回答“流量何时增长、增长了多少、主要经过哪个出站”。涉及准确的应用归属和账户计费时，应结合实际界面能够提供的信息与后台规则，不把单个数字扩大解释为设备总流量或最终账单。